# Spec Candidates > Repo-based next-spec queue for TenantPilot. > This file is not a wishlist. It tracks only open gaps that are still worth turning into new or refreshed specs. > **Last reviewed**: 2026-04-27 > **Basis**: `implementation-ledger.md`, `roadmap.md`, current `specs/` truth --- ## Candidate Rules - Work repo-based, not roadmap-aspirational. - Do not keep implemented features as active candidates. - Do not keep already-specced foundations as active candidates unless a narrower follow-up gap remains. - P0 is reserved for blockers to the next sellable release. - P1 is for enterprise and product maturity gaps. - P2 is for commercial and scale readiness. - P3 is for later platform ambitions after current release blockers close. - Existing candidate history is preserved through `Promoted to Spec`, `Deferred`, and `Superseded / Removed` notes rather than silent deletion. ## Active Candidate Queue ### P0 — Release Blockers ### Customer Review Workspace v1 - **Priority**: P0 - **Why this stays active**: The repo already has strong internal review foundations: tenant reviews, evidence snapshots, review packs, redaction paths, entitlements, audit, and RBAC-aware surfaces. What is still missing is the customer-safe read-only consumption layer that turns those internal assets into a clearly sellable review product. - **Roadmap relationship**: R2 completion / customer-facing review consumption. - **Dependencies**: - `TenantReview` - `EvidenceSnapshot` - `ReviewPack` - existing redaction behavior - workspace entitlements - tenant/workspace RBAC and audit foundations - **Scope**: - customer-safe read-only workspace or view for latest review state - latest findings and accepted risks in customer-safe form - review-pack download surface with existing redaction rules - explicit absence of admin or remediation actions - clear authorization boundaries for customer and read-only viewers - **Non-scope**: - admin settings - remediation actions - raw operator diagnostics - a broader customer portal rewrite - billing or contract workflows - **Acceptance criteria**: - an authorized customer or read-only actor can open the review workspace - latest review status, accepted risks, and key findings are visible without exposing admin controls - review-pack downloads respect existing redaction and entitlement rules - tenant and workspace isolation are enforced and tested - audit-sensitive or operator-only data is not exposed through this surface - **Notes**: This is the clearest repo-derived blocker between current internal review strength and a cleaner sellable release. ### P1 — Enterprise Maturity ### Decision-Based Governance Inbox v1 - **Priority**: P1 - **Why this stays active**: Findings, alerts, operation runs, review-pack generation, and portfolio triage already exist, but operators still work across several surfaces. The next maturity step is a single decision-oriented work surface, not more raw detail pages. - **Roadmap relationship**: Findings workflow maturity; later MSP Portfolio OS prerequisite. - **Dependencies**: - findings workflow semantics and inbox foundations from Specs 219, 221, 222, 224, 225, 230, 231 - alert routing foundation - `OperationRun` truth - portfolio triage continuity - contextual help and reason-code surfaces where helpful - **Scope**: - one operator-facing inbox for high-signal governance work - grouping or prioritization across findings, alerts, stale runs, and related attention signals - direct action links into compare, finding review, review-pack generation, or triage paths - auditable state changes such as snooze, assign, or acknowledge where already supported - **Non-scope**: - autonomous remediation - AI-generated recommendations - customer-facing inboxes - full cross-tenant workboard redesign - **Acceptance criteria**: - one surface shows prioritized governance work from more than one underlying signal family - actions route to existing product truth rather than duplicating state - visibility is capability-aware and workspace-safe - auditable state changes are recorded where the inbox mutates work state - tests prove signal grouping and authorization boundaries - **Notes**: Important, but not a P0 release blocker while Customer Review Workspace is still missing. ### Cross-Tenant Compare and Promotion v1 - **Priority**: P1 - **Why this stays active**: Portfolio triage exists, but portfolio action does not. The repo already contains an older draft spec for this direction, yet the capability is not repo-proven as a finished product workflow. - **Roadmap relationship**: MSP Portfolio & Operations. - **Existing spec**: Spec 043 exists and should be refreshed against current repo truth rather than replaced by a new broad direction. - **Dependencies**: - inventory foundations - baseline compare truth - restore and execution guardrails - audit log foundation - tenant and workspace isolation plus RBAC - **Scope**: - choose source and target tenants within allowed scope - show a structured compare preview - support a dry-run or promotion preflight before any write path - preserve auditability and scope boundaries - **Non-scope**: - blind one-click promotion - autonomous rollout - multi-cloud or multi-provider compare - full MSP control-plane redesign - **Acceptance criteria**: - operator can produce a compare preview between two allowed tenants - promotion path includes explicit preflight or dry-run semantics - authorization and tenant isolation are enforced and tested - audit trail exists for compare and promotion entry points - the slice refreshes or narrows Spec 043 instead of reopening it as a vague ambition ### Localization v1 - **Priority**: P1 - **Why this stays active**: The repo and roadmap both indicate this is still absent. It is not a backend foundation gap; it is a product maturity gap that will get more expensive as the governance surface grows. - **Roadmap relationship**: R1.9 Platform Localization v1. - **Dependencies**: - existing status and terminology catalogs - contextual help boundaries - notification and UI copy inventory on critical surfaces - locale resolution rules for workspace, user, and system context - **Scope**: - `de` and `en` on core governance surfaces - locale resolution order and fallback behavior - locale-aware formatting for dates, times, and numbers - stable machine and export formats that remain non-localized - **Non-scope**: - public website localization - broad documentation translation - retrospective translation of every legacy free-text record - marketing copy systems - **Acceptance criteria**: - core navigation, dashboard, findings, baseline compare, alerts, and operations surfaces support `de` and `en` - no raw translation keys appear on critical UI paths - fallback to English is controlled and predictable - locale-aware formatting does not affect audit or export truth - targeted regression coverage exists for fallback and key critical flows ### P2 — Commercial / Scale ### Commercial Entitlements and Billing-State Maturity - **Priority**: P2 - **Why this stays active**: The repo already has a real entitlement foundation and an existing spec for plans and billing readiness. The remaining gap is narrower: commercial lifecycle maturity, not inventing entitlements from scratch. - **Roadmap relationship**: Product Scalability & Self-Service Foundation. - **Existing spec context**: Spec 247 exists for `Plans, Entitlements & Billing Readiness`. This candidate is the follow-up gap after the current entitlement substrate, not a duplicate foundation spec. - **Dependencies**: - existing `WorkspaceEntitlementResolver` - workspace settings surfaces - review-pack entitlement gates - audit foundation - customer-facing read-only and suspension semantics where applicable - **Scope**: - commercial lifecycle states such as trial, grace, suspended/read-only, and active paid usage - clearer enforcement at key product gates - explicit disabled and read-only messaging distinct from authorization failures - audited state changes and overrides - **Non-scope**: - payment provider integration - invoicing - tax or accounting workflows - public pricing pages - **Acceptance criteria**: - central commercial state can be resolved for a workspace - at least two real behaviors are gated by lifecycle state, not scattered conditionals - read-only or suspended behavior preserves safe access to needed history or evidence while blocking disallowed actions - changes and overrides are audited - tests cover blocked and allowed paths ### External Support Desk / PSA Handoff - **Priority**: P2 - **Why this stays active**: In-app support requests are already repo-real. The remaining gap is external handoff and visible ticket linkage, not support-request creation itself. - **Roadmap relationship**: R2 support follow-through; later commercial scale. - **Dependencies**: - support request context flow from Spec 246 - support diagnostic pack - audit logging - tenant and workspace authorization boundaries - **Scope**: - outbound adapter seam for one support desk or PSA target - store and display external ticket reference - auditable create or link actions - visible product linkage back from support requests to external references - **Non-scope**: - full bidirectional sync - SLA engine - generic helpdesk product - AI support automation - **Acceptance criteria**: - a support request can create or link an external ticket through one bounded adapter - resulting ticket reference is stored and visible in the right context - failures are explicit and auditable - tenant and workspace scope are enforced and tested - the slice extends the existing support-request model instead of replacing it ### P3 — Later Platform Ambitions - No active P3 candidate from the current focus set. - `Private AI Execution & Policy Foundation` is already promoted as Spec 248 and should no longer remain in the open candidate queue. - Broader AI-assisted customer operations can return later as a follow-up only after Spec 248 and the current customer-facing release gaps are materially closed. ## Deferred / Existing Drafts Outside the Current Queue These items are still useful, but they are not the next best open specs from the current repo state. - `Policy Lifecycle / Ghost Policies`: still a valid gap, but not ahead of Customer Review Workspace or Cross-Tenant Compare. - `Workspace-level PII override for review packs`: bounded deferred follow-up from Spec 109. - `CSV export for filtered run metadata`: valid system-console follow-up, but not near the top of the queue. - `Raw error/context drilldowns for system console`: useful operator enhancement, but not ahead of current P0-P2 gaps. - UI polish snippets such as dashboard sparklines, density toggles, louder attention cards, or chooser refinements: keep out of the active spec queue until they become bounded release work. ## Promoted to Spec Historical ledger for candidates that are no longer open. Keep them here so prioritization stays clean without losing decision history. - Canonical Operation Type Source of Truth -> Spec 239 (`canonical-operation-type-source-of-truth`) - Self-Service Tenant Onboarding & Connection Readiness -> Spec 240 (`tenant-onboarding-readiness`) - Support Diagnostic Pack -> Spec 241 (`support-diagnostic-pack`) - Operational Controls & Feature Flags -> Spec 242 (`operational-controls`) - Product Usage & Adoption Telemetry -> Spec 243 (`product-usage-adoption-telemetry`) - Product Knowledge & Contextual Help -> Spec 244 (`product-knowledge-contextual-help`) - Customer Health Score -> Spec 245 (`customer-health-score`) - In-App Support Request with Context -> Spec 246 (`support-request-context`) - Plans, Entitlements & Billing Readiness -> Spec 247 (`plans-entitlements-billing-readiness`) - Private AI Execution & Policy Foundation -> Spec 248 (`private-ai-policy-foundation`) - Queued Execution Reauthorization and Scope Continuity -> Spec 149 (`queued-execution-reauthorization`) - Livewire Context Locking and Trusted-State Reduction -> Spec 152 (`livewire-context-locking`) - Evidence Domain Foundation -> Spec 153 (`evidence-domain-foundation`) - Exception / Risk-Acceptance Workflow for Findings -> Spec 154 (`finding-risk-acceptance`) - Operator Outcome Taxonomy and Cross-Domain State Separation -> Spec 156 (`operator-outcome-taxonomy`) - Operator Reason Code Translation and Humanization Contract -> Spec 157 (`reason-code-translation`) - Governance Artifact Truthful Outcomes & Fidelity Semantics -> Spec 158 (`artifact-truth-semantics`) - Operator Explanation Layer for Degraded / Partial / Suppressed Results -> Spec 161 (`operator-explanation-layer`) - Request-Scoped Derived State and Resolver Memoization -> Spec 167 (`derived-state-memoization`) - Tenant Governance Aggregate Contract -> Spec 168 (`tenant-governance-aggregate-contract`) - Record Page Header Discipline & Contextual Navigation -> Spec 192 (`record-header-discipline`) - Monitoring Surface Action Hierarchy & Workbench Semantics -> Spec 193 (`monitoring-action-hierarchy`) - Governance Friction & Operator Vocabulary Hardening -> Spec 194 (`governance-friction-hardening`) - Governance Operator Outcome Compression -> Spec 214 (`governance-outcome-compression`) - Provider-Backed Action Preflight and Dispatch Gate Unification -> Spec 216 (`provider-dispatch-gate`) - Finding Ownership Semantics Clarification -> Spec 219 (`finding-ownership-semantics`) - Humanized Diagnostic Summaries for Governance Operations -> Spec 220 (`governance-run-summaries`) - Findings Operator Inbox v1 -> Spec 221 (`findings-operator-inbox`) - Findings Intake & Team Queue v1 -> Spec 222 (`findings-intake-team-queue`) - Findings Notifications & Escalation v1 -> Spec 224 (`findings-notifications-escalation`) - Assignment Hygiene & Stale Work Detection -> Spec 225 (`assignment-hygiene`) - Findings Notification Presentation Convergence -> Spec 230 (`findings-notification-convergence`) - Finding Outcome Taxonomy & Verification Semantics -> Spec 231 (`finding-outcome-taxonomy`) - Operation Run Link Contract Enforcement -> Spec 232 (`operation-run-link-contract`) - Operation Run Active-State Visibility & Stale Escalation -> Spec 233 (`stale-run-visibility`) - Provider Boundary Hardening -> Spec 237 (`provider-boundary-hardening`) ## Superseded / Removed From Active Queue These items were previously open candidates or roadmap-fit ideas, but should no longer stay in the active queue. - `R2.0 Canonical Control Catalog Foundation`: remove from active candidates because the ledger shows a repo-real catalog, config, bindings, review integration, and test coverage. This is no longer an open candidate; it is an implemented foundation. - `Self-Service Tenant Onboarding & Connection Readiness`: remove from active candidates because it is already Spec 240 and the repo already shows meaningful adoption. - `Support Diagnostic Pack`: remove from active candidates because it is already Spec 241 and repo-adopted. - `Operational Controls & Feature Flags`: remove from active candidates because it is already Spec 242 and repo-adopted. - `Product Usage & Adoption Telemetry`: remove from active candidates because it is already Spec 243 and repo-adopted. - `Product Knowledge & Contextual Help`: remove from active candidates because it is already Spec 244; any remaining work should be narrower follow-ups, not a repeated top-level candidate. - `Customer Health Score`: remove from active candidates because it is already Spec 245 and repo-adopted. - `In-App Support Request with Context`: remove from active candidates because it is already Spec 246 and repo-implemented. - `Plans, Entitlements & Billing Readiness`: remove as a broad active candidate because Spec 247 already exists and the remaining open gap is narrower commercial lifecycle maturity. - `Private AI Execution & Policy Foundation`: remove from the active queue because Spec 248 already exists. - Company-ops items such as `Lead Capture & CRM Pipeline`, `AVV / DPA / TOM / Legal Pack`, `Vendor Questionnaire Answer Bank`, `Business Continuity / Founder Backup Plan`, and similar operating artifacts should remain outside the active product-spec queue unless a concrete product slice emerges.