# Product Roadmap

> **Status:** Active
> **Last reviewed:** 2026-05-15
> **Use for:** Current product roadmap, release themes, and prioritization context
> **Do not use for:** Implementation truth, spec completion status, or delivery guarantees without repo verification
> **Scoped maintenance:** 2026-05-15 Spec 310 product-truth/docs-drift reconciliation after Specs 307-309; 2026-05-15 Spec 309 RBAC role matrix and access boundary hardening update; 2026-05-15 Spec 308 customer-safe Decision Summary and Review Pack inclusion update; 2026-05-15 Decision Register proof-link update after Spec 307; 2026-05-15 Decision Register reconciliation update after Spec 306; 2026-05-15 tenant-owned admin surface follow-through sync after Specs 301-304; 2026-05-12 roadmap alignment after the admin workspace navigation and tenant-owned surface repair candidate intake from the repo-verified navigation/panel audit; 2026-05-06 roadmap cleanup after ledger conflict resolution and cross-domain progress / indicator semantics candidate intake; 2026-05-02 repo-based roadmap drift correction, manual-promotion backlog alignment, and enterprise-SaaS deep-research calibration against current specs, standards, and product-truth docs.
>
> Strategic thematic blocks and release trajectory.
> This is the "big picture" — not individual specs.
>
> Queue boundary: the active candidate queue lives in `docs/product/spec-candidates.md`; the promotable candidate backlog there is manual promotion only, not auto-prep; older audit-derived candidate packages remain historical inputs only.

---

## Release History

| Release | Theme | Status |
|---------|-------|--------|
| **R1 "Golden Master Governance"** | Baseline drift as production feature, operations polish | **Done** |
| **R1 cont.** | Ops canonicalization, action surface contract, ops-ux enforcement | **Done** |
| **R2 "Tenant Reviews, Evidence & Control Foundation"** | Evidence packs, stored reports, canonical control catalog, permission posture, alerts | **Partial** |
| **R2 cont.** | Alert escalation + notification routing | **Done** |

## Current Productization & Moat Priorities

This is the repo-based prioritization overlay for the next sellable lanes. The bottleneck is no longer raw backend truth alone. The next roadmap slices should make existing governance foundations customer-safe, decision-centered, auditable, and MSP-sellable before opening more backend-only islands.

Post-307/308/309 product truth:

- Decision Register operator surface is repo-real and historical/non-Greenfield through Specs 265 and 306.
- Decision Register proof/run links are repo-real after Spec 307.
- Customer-safe Decision Summary in reviews and Review Pack inclusion are repo-real after Spec 308.
- RBAC role matrix and admin/system access boundary hardening are `security-hardening completed` after Spec 309.
- Customer Review Workspace v1 Completion remains open; Spec 308 did not turn the whole customer review workspace into a fully sellable self-serve product.
- Support Access Governance remains separate from Spec 309 hardening.

| Order | Theme | Alignment status | Repo truth | Why now | Queue posture |
|---|---|---|---|---|---|
| 1 | Customer Review Workspace v1 Completion | repo-real foundation, open gap, P1 | Customer-safe review consumption is repo-real through Specs 249, 258, 259, 260, 263, and Spec 308, but a complete self-serve workspace with calm status, reason, impact, evidence basis, accepted risks, decision summary, review-pack download, and one primary next action remains open | clearest sellability lever for Governance-of-Record without creating a parallel customer portal | recommend Spec 311 |
| 2 | Localization v1 Customer-facing Surfaces | foundation-only, open gap, P1 | Spec 252 and current locale resolution are repo-real; glossary completion and customer-facing review/pack/notification adoption remain incomplete | customer-safe DACH/EU review consumption should be understandable before broader workflow packaging | recommend Spec 312 |
| 3 | Decision-Based Governance Inbox v1 | repo-real foundation, open gap, P1 | Governance inbox, findings queues, alerts, review follow-up, Spec 265 operator Decision Register, Spec 306 reconciliation, Spec 307 proof-link polish, and Spec 308 customer-safe summary/export inclusion are repo-verified | biggest remaining operator workflow gap; the need is a broader decision-centered inbox, not a Decision Register rebuild | recommend Spec 313 |
| 4 | Commercial Entitlements / Billing-State Maturity | repo-real foundation, open gap, P1/P2 | Specs 247 and 251 already resolve entitlement and lifecycle posture, but durable billing/subscription truth and artifact access by commercial state remain open | SaaS trust and lifecycle maturity should follow customer-facing surface clarity | recommend Spec 314 |
| 5 | Cross-Tenant Compare & Promotion Execution | repo-real preview/preflight, spec-backed execution follow-up | Spec 043 is repo-real for compare and preflight, and Spec 264 carries bounded execution follow-through; actual portfolio action maturity remains open until runtime/product proof is complete | portfolio action matters, but it must stay governance-first with lineage, evidence, approval, and rollback references rather than raw push mechanics | recommend Spec 315 if refresh/execution follow-through remains needed |
| 6 | Governance Artifact Lifecycle & Retention | foundation-only, open gap, P2 | Spec 262 and lifecycle-governance standards provide taxonomy-first guardrails, but governance-artifact runtime semantics are not yet productized | trust, auditability, export, and retention become more urgent after review and decision artifacts are customer-consumed | recommend Spec 316 |
| 7 | External Support Desk / PSA Handoff | repo-real foundation, open productization gap, P2 | Spec 256 and the current bounded handoff service already exist, but portfolio-safe handoff is not fully productized | MSP integration should compress follow-through work without turning TenantPilot into a helpdesk | recommend Spec 317 |
| 8 | Private AI Execution Governance Foundation / governed runtime follow-through | repo-real foundation, later open gap, P3 | Spec 248 is implemented as a governed foundation; visible runtime consumers and broader budget/result governance are still deferred | AI should remain governed foundation-first and provider-auditable after review, decision, artifact, and commercial maturity | recommend Spec 318 only as a bounded governed runtime consumer |

Explicit anti-sprawl boundaries for this priority set:

- Do not reopen risk acceptance as a broad new foundation theme; reuse the existing exception/risk-acceptance workflow and productize its customer-safe accountability trail.
- Do not reopen Decision Register v1; operator register, proof/run links, and customer-safe summary/review-pack inclusion are repo-real, while Governance Inbox and Customer Review Workspace completion remain separate.
- Do not reopen private AI as a fresh roadmap idea; the foundation already exists in `specs/248-private-ai-policy-foundation/spec.md`, and the open roadmap question is only when to promote the first governed runtime consumer.
- Do not treat the promotable candidate backlog in `docs/product/spec-candidates.md` as an automatic prep queue; those items require explicit product decisions.
- Do not prioritize Tenant Trust Score / public governance profile, insurance connectors, Copilot shadow-IT governance, local-first/on-prem proxy, or a standalone Betriebsrat mode before customer-safe review consumption, decision convergence, compliance mapping, governance packaging, and compare/promotion are materially clearer.

---

## Active / Near-term

### Governance & Architecture Hardening
Canonical run-view trust semantics, execution-time authorization continuity, tenant-owned query canon, findings workflow enforcement, Livewire trust-boundary reduction, operation-type canonicalization, provider-boundary hardening, target-scope neutrality, and governed-subject vocabulary enforcement.
Goal: Turn the new audit constitution into enforceable backend and workflow guardrails before further governance surface area lands, while preventing the Governance-of-Record platform core from drifting into provider-specific or operation-type dual semantics.

Spec 309 completes the scoped RBAC role matrix and admin/system access boundary hardening. Support Access Governance remains a separate productization candidate, not an unresolved part of Spec 309.

**Active specs**: 144
**Specced follow-through (draft)**: 149 (queued execution reauthorization), 150 (tenant-owned query canon), 151 (findings workflow backstop), 152 (Livewire context locking), 214 (governance outcome compression), 216 (provider dispatch gate), 237 (provider boundary hardening). Next foundation candidates: Canonical Operation Type Source of Truth, Provider Identity & Target Scope Neutrality, Platform Vocabulary Boundary Enforcement for Governed Subject Keys.
**Operator truth initiative** (sequenced): Operator Outcome Taxonomy (Spec 156) → Reason Code Translation (Spec 157) → Artifact Truth Semantics (Spec 158) → Governance Operator Outcome Compression (Spec 214, draft). Humanized Diagnostic Summaries for Governance Operations is now Spec 220 (draft) as the run-detail adoption slice, while Provider Dispatch Gate Unification is now Spec 216 (draft) as the adjacent hardening lane.
**Source**: architecture audit 2026-03-15, audit constitution, semantic clarity audit 2026-03-21, product spec-candidates

### UI & Product Maturity Polish
Empty state consistency, list-expand parity, workspace chooser refinement, navigation semantics.
Goal: Every surface feels intentional and guided for first-run evaluation.

Parallel manual-promotion guardrail: `docs/product/spec-candidates.md` now carries a dedicated Cross-Domain Progress / Indicator Semantics candidate group so progress, coverage, readiness, risk, usage, score, and generation-state surfaces do not keep drifting behind OperationRun-specific rules. Spec 278 is the docs-first audit slice; its follow-up lanes stay split into standards patch, metric/indicator contract foundation, shared indicator component system, quality gate, and domain migration.

Parallel immediate repair lane: `docs/product/spec-candidates.md` still carries the Admin Workspace Navigation & Tenant-owned Surface Repair candidate group as the sequencing record for workspace-home clean-sidebar versus environment-bound admin navigation. Specs 301, 302, 303, and 304 now cover the Inventory cutover, tenant-owned surface audit, Entra Groups cutover, and tenant-panel dead-code retirement. Only `navigation-contract-split` remains as a conditional manual follow-through if fresh repo evidence still shows shared contract drift.

**Active specs**: 122, 121, 112

### Secret & Security Hardening
Secret redaction integrity, provider access hardening, required permissions sidebar.
Goal: Enterprise trust — no credential leaks, no permission gaps.

**Active specs**: 120, 108, 106

### Baseline Drift Engine (Cutover)
Full content capture, cutover to unified engine, resume capability.
Goal: Ship drift detection as the complete production governance feature.

**Active specs**: 119 (cutover)

### R1.9 Platform Localization v1 (DE/EN)
UI-Sprache umschaltbar (`de`, `en`) mit sauberem Locale-Foundation-Layer.
Goal: Konsistente, durchgängige Lokalisierung aller Governance-Oberflächen — ohne Brüche in Export, Audit oder Maschinenformaten.

Repo reality: Die Locale-Foundation ist bereits repo-real. Der verbleibende Gap ist kein greenfield Localization-Foundation-Spec mehr, sondern Surface-Adoption, Copy-/Glossary-Vervollständigung und Regression-Hardening auf customer- und governance-nahen Oberflächen.

- Locale-Priorität: expliziter Override → User Preference → Workspace Default → System Default
- Workspace Default Language für neue Nutzer, User kann persönliche Sprache überschreiben
- Core-Surfaces zuerst: Navigation, Dashboard, Tenant Views, Findings, Baseline Compare, Risk Exceptions, Alerts, Operations, Audit-nahe Grundtexte
- Canonical Glossary für Governance-Begriffe (Finding, Baseline, Drift, Risk Accepted, Evidence Gap, Run) — konsistente Terminologie über alle Views
- Locale-aware Anzeigeformate für Datum, Uhrzeit, Zahlen und relative Zeiten
- Maschinen- und Exportformate bleiben invariant/stabil (keine lokalisierte Semantik in CSV/JSON/Audit-Artefakten)
- Notifications, E-Mails und operatorseitige Systemtexte nutzen die aufgelöste Locale des Empfängers
- Fallback-Regel: fehlende Übersetzungen fallen kontrolliert auf Englisch zurück; keine leeren/rohen Keys im UI
- Translation-Key Governance für Labels, Actions, Statuswerte, Empty States, Table Filters, Notifications und Validation-/Systemtexte
- HTML/UI i18n-Foundation: korrektes `lang`/Locale-Setup, keine hartcodierten kritischen UI-Strings, layouts sprachrobust
- Search/Sort/Filter auf kritischen Listen für locale-sensitives Verhalten prüfen
- QA/Foundation: Missing-Key Detection, Locale Regression Tests, Pseudolocalization Smoke Tests für kritische Flows

**Queue status**: recommended near-term Spec 312 after Customer Review Workspace v1 Completion; the historical foundation package is `specs/252-platform-localization-v1/spec.md`, and the remaining follow-through is `Localization v1 Customer-facing Surfaces` / `Customer-Facing Localization Adoption v1` in `docs/product/spec-candidates.md` as manual promotion only, not auto-prep.

### Product Scalability & Self-Service Foundation
Self-service and supportability foundation that keeps TenantPilot operable as a low-headcount, AI-assisted SaaS instead of drifting into manual onboarding, manual support, and founder-dependent customer operations.
**Goal**: Productize the recurring work around onboarding, diagnostics, support context, plan limits, and customer guidance so that new customers can evaluate, onboard, operate, and request help with minimal manual intervention.

- Self-Service Tenant Onboarding & Connection Readiness: guided tenant setup, consent readiness, provider connection checks, permission diagnostics, setup progress, completion score, and concrete next actions
- Support Diagnostic Pack: diagnostic bundles for workspace, tenant, OperationRun, Finding, ProviderConnection, and report contexts with relevant health state, permissions, run context, errors, audit references, and AI-readable summaries
- In-App Support Request with Context: support entry points that attach workspace, tenant, run/finding/report references, severity, diagnostic pack reference, and ticket reference back into TenantPilot
- Product Knowledge & Contextual Help: help registry for feature explanations, status meanings, error guidance, permission rationale, troubleshooting hints, and docs links; also usable as the source layer for later AI support
- Plans, Entitlements & Billing Readiness: plan model, feature gates, tenant/workspace/user/report/export/retention limits, trial state, grace periods, billing status, and audited plan changes
- Demo & Trial Readiness: seeded demo workspaces, sample tenants, sample baselines/findings/reports, demo reset support, trial provisioning checklist, and sample-data mode where appropriate
- Customer-facing transparency hooks: product surfaces should be designed so customer read-only views, review workspaces, support requests, and review-pack downloads can reuse the same underlying entities instead of becoming parallel one-off features
- Private AI readiness hooks: support, review, diagnostic, and decision surfaces should be designed so later AI assistance can use governed context builders, data classification, usage budgets, local/private model policies, cache fingerprints, and human approval gates instead of direct feature-level AI calls

**Repo reality**: this is no longer an unspecced greenfield foundation. Onboarding, diagnostics, support requests, contextual help, entitlements, telemetry, customer health, and operational controls are already spec-backed or repo-real; the remaining roadmap gap is broader customer/self-service productization plus the narrower `Billing & Subscription Truth Layer v1` follow-up tracked in `docs/product/spec-candidates.md`.

---

## Planned (Next Quarter)

### Workspace-first / ManagedEnvironment Core Cutover Pack
Development-stage clean-cutover architecture lane for moving TenantPilot away from a `Tenant`-centric core before more multi-provider, portfolio, and package surfaces accumulate additional tenant- and Microsoft-specific coupling.
**Goal**: keep `Workspace` as the primary SaaS context, introduce `ManagedEnvironment` as the secondary managed target context, and perform the cutover without legacy compatibility burden.

**Roadmap posture**: manual-promotion-only spec pack, not auto-prep, and explicitly not a "rename Tenant" initiative.

**Hard cutover rules**:

- no legacy `Tenant` compatibility layer
- no `/admin/t/{tenant}` compatibility route
- no dual-read from `tenant_id` and `managed_environment_id`
- no dual-write
- no production-data backfill
- no deprecated `Tenant` model left behind as an active domain model
- no Microsoft-specific identity, Graph, or Intune fields on `ManagedEnvironment`
- `tenant` remains allowed only in Microsoft-provider copy, payload metadata, or external terminology such as `Microsoft Entra Tenant ID`
- Filament tenant context must be `Workspace`
- `ManagedEnvironment` remains a secondary domain context inside a `Workspace`

**Recommended spec order**:

1. `279 Workspace-first Managed Environment Core Cutover`
2. `280 Filament Workspace Tenancy & Environment Routing Cutover`
3. `281 Provider Connection, Provider Scope & Microsoft Profile Extraction`
4. `282 Governance Artifact Retargeting to ManagedEnvironment`
5. `283 Provider Capability Registry v1`
6. `284 Provider-neutral Artifact Source Taxonomy v1`
7. `285 Workspace-first RBAC & Environment Access Scoping`
8. `286 UI Copy, IA & Localization Neutralization`
9. `287 Cutover Quality Gates & No-Legacy Enforcement`

**Sequencing note**: Specs 279-282 are the hard cutover. Specs 283-284 make the new core provider-neutral and package-ready. Specs 285-287 keep RBAC, copy, and quality gates from drifting back toward tenant- or Microsoft-centric core assumptions.

**Follow-on series after the cutover pack**:

1. `288 Package Execution Contract v1`
2. `289 Guided Operations Recommendation Layer v1`
3. `290 Microsoft Governance Package Starter Pack v1`
4. `291 Virtual Consultant / External Portal Guidance v1`

### R2.0 Canonical Control Catalog Foundation
Framework-neutral canonical control core that bridges the shipped governance engine and later readiness or reporting overlays.
**Goal**: Give baselines, drift, findings, exceptions, evidence, and reports one shared control object before framework-specific mappings land.

- Framework-neutral canonical domains, subdomains, and control themes
- Detectability classes, evaluation strategies, evidence archetypes, and artifact suitability
- Microsoft subject and workload bindings for tenant-near technical controls
- Small seed catalog for v1 families such as strong authentication, conditional access, privileged access, endpoint baseline or hardening, sharing boundaries, mail protection, audit retention, and delegated admin boundaries
- Referenceable from Baseline Profiles, Compare and Drift, Findings, Exceptions, StoredReports, and EvidenceItems
- Foundation for later framework mappings, readiness views, customer review workspaces, and auditor packs
- Explicitly not a late compliance feature: this is the semantic platform layer for tenant reviews, evidence packs, findings, exceptions, stored reports, and future readiness views

### R1.x Foundation Hardening — Governance Platform Anti-Drift
Stabilize the Governance-of-Record platform semantics before additional Microsoft domains, compliance overlays, or multi-cloud execution expand the surface area.
**Goal**: Keep Golden Master Governance from becoming provider-specific feature growth by hardening the platform seams underneath OperationRuns, ProviderConnections, governed subjects, and shared vocabulary.

- Canonical Operation Type Source of Truth for persistence, dispatch, UI labels, audit, alerts, notifications, and reporting
- Provider Boundary Hardening so provider-specific behavior stays inside provider adapters and registries
- Provider Identity & Target Scope Neutrality so Entra-specific identifiers do not become generic platform truth
- Platform Vocabulary Boundary Enforcement for Governed Subject Keys so `policy_type` and similar provider/domain terms do not leak into the platform core
- Codebase Quality & Engineering Maturity hardening so the platform remains enterprise-maintainable while the governance surface grows: System Panel least-privilege capabilities, static-analysis baseline, architecture-boundary guard tests, and targeted decomposition of large Filament/service hotspots
- No AWS/GCP/SaaS connector implementation in this slice; this is anti-drift foundation work only

### R2 Completion — Evidence & Exception Workflows
- Review pack export (`specs/109-review-pack-export/spec.md` — repo-real follow-through)
- Exception/risk-acceptance workflow for Findings → Spec 154 (repo-real foundation; the next product gap is accountability-trail productization in customer-safe review, expiry/re-review visibility, and management-ready reporting)
- Formal evidence/review-pack entity foundation -> `specs/153-evidence-domain-foundation/spec.md` + `specs/155-tenant-review-layer/spec.md`
- Workspace-level PII override for review packs → deferred from 109
- Customer Review Workspace Productization v1 -> `specs/258-customer-review-productization/spec.md` and the adjacent follow-through in `specs/259-compliance-evidence-mapping/spec.md` + `specs/260-governance-service-packaging/spec.md`
- Auditor Pack Delivery & Executive Export v1 -> manual-promotion follow-up that builds on `specs/109-review-pack-export/spec.md`, `specs/153-evidence-domain-foundation/spec.md`, `specs/155-tenant-review-layer/spec.md`, `specs/258-customer-review-productization/spec.md`, `specs/259-compliance-evidence-mapping/spec.md`, and `specs/260-governance-service-packaging/spec.md` rather than reopening them as active queue work.
- Support Diagnostic Pack → connect tenant/review/finding/report/operation contexts into a reusable support bundle before support demand scales
- In-App Support Request with Context → attach the relevant diagnostic pack and ticket reference to support workflows without creating a separate support data model
- Product Knowledge & Contextual Help → reuse canonical glossary, outcome/reason semantics, and report/finding terminology as the product-help source layer

### Findings Workflow v2 / Execution Layer
Turn findings from a reviewable register into an accountable operating flow with clear ownership, personal queues, intake, hygiene, and minimal escalation.
**Scope direction**:
- Clarify owner versus assignee semantics and accountability language first
- Add operator work surfaces such as "Assigned to me" and an unassigned intake queue with basic claim flow
- Harden assignment hygiene, stale-work detection, and resolved-versus-verified outcome semantics
- Reuse the existing alerting foundation for assignment, reopen, due-soon, and overdue notification flows
- Keep comments, external ticket handoff, and cross-tenant workboards as later slices instead of forcing them into the first workflow iteration

### Workspace, Tenant & Managed Object Lifecycle Governance
Strategic lifecycle taxonomy for workspaces, tenants, managed provider objects, evidence, backups, restoreability, export, retention, and purge.
**Goal**: Prevent local lifecycle fixes such as “Ghost Policies” from introducing inconsistent deletion semantics before TenantPilot has one enterprise-grade lifecycle model.

TenantPilot must distinguish at least these lifecycle dimensions:

- Local record lifecycle: active, archived, locally removed, purge scheduled, purged
- Provider presence lifecycle: present, missing from provider, provider deleted, reappeared
- Operator suppression lifecycle: visible, ignored / suppressed, restored to visibility
- Commercial / workspace lifecycle: trial, active, grace, suspended read-only, closed
- Retention / compliance lifecycle: retained, export requested, deletion requested, deletion scheduled, legal hold / retention hold, purge due, purged
- Restoreability lifecycle: restorable, metadata only, blocked by dependency, not restorable, expired by retention

**Roadmap posture**: The taxonomy-first foundation is now captured in `specs/262-lifecycle-governance-taxonomy/spec.md`. The narrower runtime follow-through is `Workspace & Tenant Closure Lifecycle v1` in `docs/product/spec-candidates.md`, and it remains manual promotion only, not auto-prep.

**Important boundary**: Do not implement a narrow policy-only ghost lifecycle patch, Laravel `SoftDeletes` rollout, workspace deletion flow, tenant deletion flow, purge engine, or retention framework before this lifecycle taxonomy is agreed.

**Approved narrow exception**: Spec 261 (`provider-missing-policy-visibility`) now captures the bounded policy-only provider-missing truth correction. Keep future lifecycle, deletion, retention, and purge work taxonomy-first; do not generalize Spec 261 into the broader lifecycle model.

**Spec-backed foundation**: `specs/262-lifecycle-governance-taxonomy/spec.md` is the agreed taxonomy-first package. Keep closure/runtime follow-through separate from the taxonomy and promote it only through `Workspace & Tenant Closure Lifecycle v1` in `docs/product/spec-candidates.md`.

### Platform Operations Maturity
- CSV export for filtered run metadata (deferred from Spec 114)
- Raw error/context drilldowns for system console (deferred from Spec 114)
- Multi-workspace operator selection in `/system` (deferred from Spec 113)

### Solo-Founder SaaS Automation & Operating Readiness
Internal operating-system track for running TenantPilot as a lean, AI-assisted SaaS company with repeatable customer acquisition, onboarding, support, billing, security review, and release communication.
**Goal**: Keep company operations from becoming founder-only manual work while the product moves from pilots to repeatable customer delivery.

- Lead Capture & CRM Pipeline: website lead forms, demo requests, waitlist, lead status, pilot status, customer status, follow-up reminders, and meeting notes capture
- Demo Environment Automation: repeatable demo workspace, sample tenant data, reset flow, demo scripts, and separate demo stories for MSP and enterprise IT buyers
- Trial Provisioning Workflow: trial request intake, plan/limit assignment, provisioning checklist, onboarding status, trial expiry, conversion path, and grace handling
- Billing & Contract Readiness: plan matrix, offer templates, invoicing flow, payment/billing status, trial-to-paid process, cancellation process, and grace-period handling
- AVV / DPA / TOM / Legal Pack: reusable customer-facing legal and data-processing artifacts aligned with the actual product data model and hosting setup
- Security Trust Pack Light: hosting overview, data categories, least-privilege permission model, RBAC model, retention, backup, audit logging, subprocessors, and “what we do not store” documentation
- Support Desk + AI Triage: support mailbox or ticket system, categories, priorities, macros, known issues, AI triage, answer drafts, and linkage to TenantPilot diagnostic packs
- Private AI Operating Model: default no customer/tenant data to public AI APIs, local/private-first AI processing, explicit customer/workspace opt-in for non-local providers, AI disclosure wording, and operating rules for model hosting, retention, cost, and approval
- Knowledge Base Pipeline: public docs, onboarding docs, troubleshooting docs, internal runbooks, and a maintained source set for AI-assisted support
- Monitoring & Incident Runbooks: uptime, queues, failed jobs, error tracking, backups, storage, certificates, Graph failure rates, status page, incident templates, postmortem templates, and customer communication templates
- Release & Customer Communication Automation: customer changelog, release notes, support notes, migration notes, breaking-change markers, known limitations, and docs-update checklist

**Active specs**: — (not yet specced; company-ops track, not all items need product specs)

### Additional Solo-Founder Scale Guardrails
Cross-cutting operating guardrails that prevent TenantPilot from scaling through hidden manual work, unclear customer health, missing operational controls, ad-hoc customer communication, or unmanaged founder dependency.
**Goal**: Make repeatability, observability, controllability, and delegability explicit before customer volume makes the gaps expensive.

- Product Usage & Adoption Telemetry: privacy-aware usage signals for onboarding completion, feature adoption, report exports, failed flows, support-triggering surfaces, inactive customers, and trial conversion indicators
- Customer Health Score: derived customer/workspace health indicators from login/activity, provider health, last sync, baseline compare freshness, open high findings, overdue SLAs, expiring risk acceptances, failed runs, support load, and review-pack readiness
- Operational Controls & Feature Flags: global/workspace kill switches and scoped controls for risky features, restore actions, exports, AI functions, provider actions, trials, maintenance scenarios, and temporary read-only states
- Customer Lifecycle Communication: structured lifecycle messages for welcome, onboarding, trial reminders, provider health warnings, review-pack readiness, risk-expiry reminders, release updates, incidents, renewal, payment issues, and churn feedback
- Vendor Questionnaire Answer Bank: reusable security/procurement answers aligned with the Security Trust Pack, product data model, Microsoft permissions, hosting, AI usage, subprocessors, retention, backup, deletion, and incident handling
- Product Intake & No-Customization Governance: feature-request intake, roadmap-fit classification, no-custom-work policy, customer exception handling, productization rules, and a clear path from request → candidate → spec → release or rejection
- Support Severity Matrix & Runbooks: P1–P4 definitions, incident vs support vs bug vs feature request distinction, response expectations by plan, escalation rules, known-issue handling, and internal support runbooks
- Data Retention, Export & Deletion Self-Service: customer-facing and operator-facing flows for export, archive, deletion request handling, trial data expiry, workspace deactivation, and evidence/report retention visibility; depends on the shared Workspace, Tenant & Managed Object Lifecycle Governance taxonomy before destructive or retention-sensitive flows are implemented
- Business Continuity / Founder Backup Plan: access documentation, secret management, emergency contacts, deployment and restore runbooks, incident templates, DNS/domain/hosting ownership, billing access, and vacation/sickness fallback

**Active specs**: — (not yet specced; guardrail track, only product-impacting items should become specs)

---

## Mid-term (2–3 Quarters)

### Product Usage, Customer Health & Operational Controls
Product-side implementation lane for the highest-impact solo-founder guardrails: adoption telemetry, customer/workspace health scoring, and operator controls/feature flags.
**Goal**: Give the founder/operator a measurable, controllable view of customer adoption, risk, and operational safety without relying on manual checks across logs, support tools, billing tools, and product screens.
**Why it matters**: Low-headcount SaaS only works if the product shows where customers are stuck, which workspaces are unhealthy, and which features can be safely paused or limited during incidents.
**Depends on**: Self-Service Tenant Onboarding & Connection Readiness, Support Diagnostic Pack, Plans / Entitlements & Billing Readiness, ProviderConnection health, OperationRun truth, Findings workflow, StoredReports / EvidenceItems, and audit log foundation.
**Scope direction**: Start with privacy-aware product telemetry, derived customer/workspace health indicators, and a minimal operational controls registry. Avoid building a full analytics platform, CRM, or customer-success suite in the first slice.

### Private AI Execution Governance Foundation
Strategic AI platform foundation for using AI inside TenantPilot without hard-coding public cloud AI calls, leaking tenant data, losing cost control, or forcing later rewrites.
**Repo reality**: `specs/248-private-ai-policy-foundation/spec.md` already captures the governed AI foundation. The open roadmap gap is no longer whether a foundation should exist, but when to promote the first governed runtime consumer.
**Goal**: Make AI local/private-first, explicitly governed, budgeted, cacheable, auditable, and human-approved. External public AI providers are disabled by default and only usable through workspace-level opt-in, data classification, redaction, usage limits, and approval gates.
**Why it matters**: TenantPilot sells governance, compliance readiness, evidence, and tenant trust. AI cannot be bolted on through direct feature-level API calls. The platform needs a reusable execution boundary so support summaries, finding explanations, review packs, decision packs, and customer communications can use AI later without rebuilding privacy, cost, provider, approval, and audit controls each time.
**Depends on**: Product Knowledge & Contextual Help, Support Diagnostic Pack, Decision Pack Contract & Approval Workflow, Product Usage & Adoption Telemetry, Plans / Entitlements & Billing Readiness, Operational Controls & Feature Flags, Security Trust Pack Light, audit log foundation, and workspace/RBAC isolation.
**Scope direction**: Build the foundation before broad AI features: AI use case registry, AI provider registry, workspace AI policy, AI data classification, AI context builders, AI policy gate, AI budget gate, AI result store/cache, AI usage ledger, and AI audit trail. Start with local/private and customer-hosted model compatibility; keep external provider support optional and explicit.
**Priority note**: This remains strategic, but it should stay behind current customer-review productization, decision convergence, compliance mapping, governance packaging, and compare/promotion gaps.

**Core principles**:
- AI is never called directly from feature code; every AI action goes through governed use cases, policy gates, budget gates, context builders, provider adapters, cache/result storage, and audit trails
- Default posture: no customer or tenant data is sent to external public AI APIs
- Local/private/customer-hosted/EU-private model execution is the preferred path for tenant/customer data
- External public AI providers require explicit workspace opt-in, allowed data classes, redaction, budgets, disclosure, and human approval where needed
- Raw provider payloads, personal data, and customer-confidential context are never sent to external models by default
- Customer-facing, tenant-changing, risk-accepting, legal, or compliance-relevant AI outputs require human approval
- AI outputs should be fingerprinted, cacheable, source-linked, and reproducible enough for governance review

**Foundation components**:
- AI Use Case Registry: allowed data classes, model classes, approval requirements, output visibility, retention, cacheability, cost ceiling, and context-size limits per use case
- AI Provider Registry: disabled, local/private, customer-hosted OpenAI-compatible, TenantPilot-private, EU-private, and external provider adapters with trust-boundary metadata
- Workspace AI Policy: disabled, local-only, private-only, EU-only, external-allowed-with-redaction, or explicit external-allowed modes
- AI Data Classification: product knowledge, operational metadata, tenant config summary, redacted provider payload, raw provider payload, personal data, customer-confidential context, and legal/compliance statements
- AI Context Builders: sanitized, purpose-specific context assembly instead of sending raw tenant/provider data to models
- AI Usage Budgeting: credits, monthly caps, model-tier routing, queue priority, cost estimates, and cache/fingerprint reuse
- AI Result Store & Cache: fingerprinted outputs with provenance, freshness, invalidation, source references, and reuse controls
- AI Audit Trail: use case, provider, model class, data class, purpose, context hash, output hash, cost estimate, cache hit/miss, approval state, and result usage

### AI-Assisted Customer Operations
AI-assisted customer operations layer for support, reviews, summaries, release communication, and customer-facing explanations, explicitly bounded by private AI execution policy, human approval, and product auditability.
**Goal**: Use AI to prepare, summarize, classify, and draft customer operations work while keeping tenant-changing actions, customer commitments, legal statements, and external communications under human approval.
**Why it matters**: TenantPilot can stay lean only if support, customer reviews, release communication, and diagnostics are structured enough for AI assistance without becoming ungoverned automation or uncontrolled public-model data processing.
**Depends on**: Private AI Execution Governance Foundation, Product Knowledge & Contextual Help, Support Diagnostic Pack, In-App Support Request, StoredReports / EvidenceItems, Findings workflow maturity, release-note discipline, and company support-desk structure.
**Scope direction**: Start with AI-generated support summaries, finding explanations, tenant review summaries, diagnostic summaries, release-note drafts, and support-response drafts. Prefer local/private execution for tenant/customer data. Avoid autonomous tenant remediation, automatic risk acceptance, automatic legal commitments, or customer-facing messages without review.

### Decision-Based Operating Foundations
Constitution hardening for decision-first governance, workflow-first navigation, surface taxonomy, and primary-vs-evidence surface refactoring.
**Goal**: Prepare TenantPilot for a quieter, decision-centered operating model where primary surfaces ask for action and deeper technical detail stays available on demand.
**Why it matters**: Governance inboxes, actionable alerts, and later autonomous-governance features will fail if they land on top of detail-heavy, entity-first navigation. This is the UX/product prerequisite layer for the later MSP Portfolio OS direction.
**Depends on**: Current constitution and action-surface hardening, operator-truth work, existing navigation/context specs.
**Scope direction**: First the constitution/rule delta, then a surface / IA classification of current product surfaces, then bounded retrofits that demote detail-first flows behind progressive disclosure instead of creating more top-level pages.
**Concrete next slice**: `Governance Decision Surface Convergence` is the repo-based follow-up. Do not reopen the first Governance Inbox as a greenfield concept.

### MSP Portfolio & Operations (Multi-Tenant)
Multi-tenant health dashboard, SLA/compliance reports (PDF), cross-tenant troubleshooting center.
**Source**: 0800-future-features brainstorming, identified as highest priority pillar.
**Prerequisites**: Decision-Based Operating Foundations, Cross-tenant compare (Spec 043 — draft only).
**Later expansion**: portfolio operations should eventually include a cross-tenant findings workboard once tenant-level inbox and intake flows are stable.
**Concrete next slice**: `Cross-Tenant Compare & Promotion v1` is the repo-based move from portfolio visibility toward portfolio action.

### Human-in-the-Loop Autonomous Governance (Microsoft-first, Provider-extensible Decision-Based Operating)
Continuous detection, triage, decision drafting, approval-driven execution, and closed-loop evidence for governance actions across the Microsoft-first workspace portfolio, while keeping the decision model provider-extensible for later non-Microsoft domains.
**Goal**: Move TenantPilot from Microsoft tenant search-and-troubleshoot workflows to decision-based governance operations. Customers and operators should not have to click through tenants, runs, findings, reports, logs, and evidence to discover what needs attention. TenantPilot should detect relevant work, gather context, summarize impact, propose safe next actions, and present decision-ready items. The first product scope stays Microsoft tenant governance; the underlying decision model should avoid hard-coding Microsoft-only assumptions where a provider-neutral abstraction is already available.
**Why it matters**: This is the longer-term MSP Portfolio OS layer. TenantPilot becomes the decision control plane for accountable Microsoft tenant governance first, not just a browser for runs, evidence, and tenant state. Detail pages remain available as evidence and diagnostics, but the default operating model becomes guided decisions, not manual investigation.
**Depends on**: Decision-Based Operating Foundations, Product Knowledge & Contextual Help, Support Diagnostic Pack, Customer Health Score, MSP Portfolio & Operations surfaces, drift/findings/exception maturity, actionable alerts with structured payloads, canonical operation/evidence truth, operational controls, and human approval gates.
**Scope direction**: Start with a Governance Inbox / Action Center, decision items, decision packs, actionable alerts, and approval-gated workflows for Microsoft tenant governance. Later add automation policies, guardrails, maintenance windows, dual approval, before/after evidence automation, and limited remediation execution. Keep human approval and auditability central; avoid blind autopilot remediation.

**Core workflow**:
- Detect relevant governance work automatically
- Group, deduplicate, and prioritize related signals
- Generate a decision pack with summary, impact, evidence, affected tenants/policies, recommended actions, and confidence
- Present clear actions such as approve, reject, snooze, assign, accept risk, create ticket, run compare, generate review pack, or request evidence
- Require human approval for tenant-changing, customer-facing, or risk-accepting actions
- Execute approved follow-up through OperationRuns or controlled workflows
- Verify outcome and attach before/after evidence
- Keep audit trail across detection, recommendation, approval, execution, and verification

**Anti-pattern**: Do not make customers manually troubleshoot by navigating through raw runs, logs, tables, and details as the primary workflow. Raw surfaces are evidence and diagnostics, not the main operating model.

### Drift & Change Governance ("Revenue Lever #1")
Change approval workflows (DEV→PROD with audit pack), guardrails/policy freeze windows, tamper detection.
**Source**: 0800-future-features brainstorming.
**Prerequisite**: Drift engine fully shipped, findings workflow mature.

### Standardization & Policy Quality ("Intune Linting")
Policy linter (naming, scope tag requirements, no All-Users on high-risk), company standards as templates, policy hygiene (duplicate finder, unassigned, orphaned, stale).
**Source**: 0800-future-features brainstorming.

### PSA / Ticketing Handoff
Outbound handoff from findings into external service-desk or PSA systems with visible `ticket_ref` linkage and auditable "ticket created/linked" events.
**Scope direction**: start with one-way handoff and internal visibility, not full bidirectional sync or full ITSM modeling.

### Compliance Evidence Mapping v1
Versioned mapping layer that connects technical findings, accepted risks, evidence, and review outcomes to customer-safe control and readiness views without certification claims.
**Goal**: Translate existing governance truth into control- and audit-ready language for German midmarket and compliance-oriented customers while keeping technical findings clearly separate from regulatory interpretation.
**Why it matters**: Canonical controls and evidence are already repo-real foundations. The missing value is not another control catalog, but a customer-safe mapping layer that explains why a finding matters, what evidence exists, and which control or readiness statement it supports.
**Depends on**: Canonical Control Catalog Foundation, Evidence-to-Control mapping, StoredReports / EvidenceItems foundation, Tenant Review runs, Customer Review Workspace Productization, Findings + Risk Acceptance workflow, and export maturity.
**Scope direction**: Start with versioned control interpretations plus one bounded overlay layer. Avoid certification promises, legal guarantees, or framework-specific deep branching inside the platform core.
**Modeling principle**: Compliance and governance requirements are modeled through a framework-neutral canonical control catalog plus technical interpretations and versioned framework overlays, not as separate technical object worlds per framework. Readiness views, evidence packs, baseline libraries, and auditor outputs are generated from that shared domain model.

**Layering**:
- **S1**: framework-neutral Canonical Control Catalog plus TenantPilot technical interpretations as the normative control core
- **S2**: CIS Baseline Library as a template and library layer built on top of the canonical catalog, not a separate control object model
- **S3**: NIS2 and BSI readiness views as mapping and readiness layers built on the same canonical catalog and evidence model
- ISO and COBIT belong primarily in governance, assurance, ISMS, and readiness overlays on top of the shared catalog, not as separate technical subject or control worlds

- Separate canonical control catalog versions, technical interpretation versions, framework overlay versions, and customer/MSP profile versions
- Map canonical controls to evidence sources, evaluation rules, and manual attestations when automation is partial
- Keep CIS baseline templates and NIS2 / BSI readiness views as downstream layers on top of the shared canonical control model
- Keep ISO / COBIT semantics in governance-assurance and ISMS-oriented overlays rather than introducing a second technical control universe
- Avoid framework-specific one-off reports that bypass the common evidence, findings, exception, and export pipeline

### Governance-as-a-Service Packaging v1
Recurring governance deliverables for MSPs and customer stakeholders built on review packs, accepted risks, evidence, and control mapping.
**Goal**: Let MSPs deliver monthly or quarterly governance packages without manual screenshot decks, Excel exports, or ad-hoc PowerPoint work.
**Why it matters**: This is the commercial layer that turns already-strong review, evidence, and accepted-risk foundations into a repeatable MSP revenue surface. TenantPilot should sell not only truth capture, but calm customer-safe governance reporting.
**Depends on**: Customer Review Workspace Productization, Compliance Evidence Mapping v1, Review Packs, StoredReports / EvidenceItems, Findings + Risk Acceptance workflow, export pipeline maturity, localization, and entitlements.
**Scope direction**: Start with executive summary, top findings, accepted risks, open decisions, evidence links, management-ready review-pack export, and bounded MSP branding. Avoid CRM/newsletter tooling, PSA replacement, or raw operator-data dumps as the default output.

### Entra Role Governance
Expand TenantPilot's governance coverage into Microsoft Entra role definitions and assignments as a first-class identity administration surface.
**What it means**: Inventory and visibility for built-in and custom role definitions. Visibility into role assignments and governance-relevant changes. Review-ready representation of identity administration posture.
**Why it matters**: Identity role governance is central to audit readiness and privilege control. Strengthens TenantPilot beyond device configuration into identity governance.
**Scope direction**: Start with visibility, inventory, and governance-oriented reviewability. Avoid prematurely turning this into a full attestation workflow block.

### SharePoint Tenant-Level Sharing Governance
Extend TenantPilot into high-value Microsoft 365 data-governance controls by covering tenant-level SharePoint and OneDrive sharing settings.
**What it means**: Visibility into tenant-wide sharing and external access posture. Governance-oriented review surface for high-risk sharing controls. Alignment with customer demand for audit-ready data-sharing posture.
**Why it matters**: Tenant-level sharing controls are critical for data exposure and external collaboration governance. Expands TenantPilot into a high-value non-Intune policy domain without becoming a generic M365 admin mirror.
**Scope direction**: Start at tenant-level settings, not full site-level governance. Position as governance and reviewability, not full SharePoint administration.

### Enterprise App / Service Principal Governance
Add governance coverage for enterprise applications and service principals, especially around privileged permissions, expiring credentials, and review workflows.
**What it means**: Visibility into enterprise apps and service principals. Detection of expiring secrets and certificates. Governance surfaces for privileged app access and renewal workflows.
**Why it matters**: App identities are a major cloud governance and security pain point for MSPs and enterprise customers. Creates strong customer-facing value beyond tenant configuration backup and restore.
**Scope direction**: Start with visibility, expiry monitoring, and governance workflows. Avoid collapsing this into app-consent policy coverage alone.

### Security Posture Signals
Expand TenantPilot's evidence layer with high-value security posture signals that support customer reviews, audit preparation, and recurring governance reporting.
**What it means**: Defender Vulnerability Management exposure and remediation-oriented signals. Backup success/failure and protection-state signals. Additional evidence inputs for review packs and executive reporting.
**Why it matters**: Strengthens TenantPilot's audit and review story without turning it into a remediation engine. Helps prove operational effectiveness in recurring customer reviews.
**Scope direction**: Treat these as evidence/signal domains, not policy domains. Prioritize reporting, history, and correlation over operational ownership.

---

## Long-term

### Tenant-to-Tenant / Staging→Prod Promotion
Compare/diff between tenants, mapping UI (groups, scope tags, filters, named locations, app refs), promotion plan (preview → dry-run → cutover → verify).
**Source**: 0800-future-features and `specs/043-cross-tenant-compare-and-promotion/spec.md`.

### Recovery Confidence ("Killer Feature")
Automated restore tests in test tenants, recovery readiness report, preflight score.
**Source**: 0800-future-features brainstorming.

### Security Suite Layer
Security posture score, blast radius display, opt-in high-risk enablement.
**Source**: 0800-future-features brainstorming.

### Script & Secrets Governance
Script diff + approval + rollback, secret scanning, allowlist/signing workflow.
**Source**: 0800-future-features brainstorming.

---

## Infrastructure & Platform Debt

| Item | Risk | Status |
|------|------|--------|
| No explicit company automation roadmap linkage | Risk that sales, support, billing, legal, and customer communication become founder-only manual work | Covered by Solo-Founder SaaS Automation & Operating Readiness |
| No shared lifecycle taxonomy for workspace, tenant, managed-object, retention, export, purge, and restoreability states | Local fixes such as ghost-policy handling, workspace deactivation, tenant removal, retention, or purge can create inconsistent deletion semantics and audit gaps | Covered by Workspace, Tenant & Managed Object Lifecycle Governance candidate |
| Governance-artifact lifecycle runtime is still missing | Lifecycle taxonomy and point retention rules exist, but governance artifacts still lack one runtime contract for immutable identity, hold, export, delete, and suspended/read-only behavior | Covered by Governance Artifact Lifecycle & Retention v1 |
| No structured support diagnostic bundle yet | Support cases require manual context gathering across tenants, runs, findings, providers, and reports | Covered by Product Scalability & Self-Service Foundation |
| No bounded support-access governance package yet | Break-glass, system access, and future impersonation/support access could drift without customer-visible TTL, reason, approval, and export semantics | Covered by Enterprise Access Boundary & Support Access Governance v1 |
| No formal security trust pack yet | Enterprise sales and customer security reviews require repeated manual explanations | Covered by Solo-Founder SaaS Automation & Operating Readiness |
| Auditor-ready executive export is not yet productized | Review truth still stops short of calm auditor-/executive-ready delivery even though the spec package now exists | Covered by `specs/263-auditor-pack-executive-export/spec.md` |
| Cross-tenant promotion execution is missing | Compare preview and preflight stop short of the actual portfolio action even though the execution spec package now exists on this branch | Covered by `specs/264-cross-tenant-promotion-execution/spec.md` |
| Residual admin workspace navigation contract drift may remain | Specs 301-304 closed the Inventory cutover, route audit, groups cutover, and tenant-panel dead-code cleanup; only a later contract split may still be needed if new repo evidence shows workspace-home and environment-bound navigation rules colliding again | Covered by the conditional `navigation-contract-split` follow-up in `docs/product/spec-candidates.md` |
| Customer Review Workspace v1 completion is still open | Specs 258 and 308 make the workspace and customer-safe decision summary/review-pack inclusion repo-real, but the complete self-serve customer consumption experience is not yet fully productized | Covered by `311-customer-review-workspace-v1-completion` in `docs/product/spec-candidates.md` |
| Customer-facing localization adoption is incomplete | Repo-real locale groundwork is not yet fully productized across customer-safe governance surfaces | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
| Billing and subscription truth is missing | Commercial readiness still stops short of a durable billing/subscription truth layer | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
| Stored reports still lack a clear product surface | Retained evidence and review artifacts remain harder to consume than they should be | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
| Workspace and tenant closure follow-through is not started | The taxonomy exists, but closure/runtime semantics are not yet productized | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
| First governed AI runtime consumer is missing | The governed AI foundation exists, but no bounded runtime consumer proves the model end-to-end | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
| No no-customization governance yet | Customer-specific requests can silently turn the product into consulting work and create hidden maintenance obligations | Covered by Additional Solo-Founder Scale Guardrails |
| No business-continuity / founder-backup plan yet | Solo-founder operations create continuity risk for incidents, illness, vacation, access recovery, and customer trust | Covered by Additional Solo-Founder Scale Guardrails |
| No `.env.example` in repo | Onboarding friction | Open |
| CI pipeline config status drift | Roadmap debt list may be stale because workflow files exist and should be re-audited; align with static-analysis and architecture-boundary gates | Review needed |
| No PHPStan/Larastan | No static analysis; covered by `Static Analysis Baseline for Platform Code` spec candidate | Open |
| Thin architecture-boundary enforcement | Product tests are strong, but architecture-level guardrails need expansion; covered by `Architecture Boundary Guard Tests` spec candidate | Open |
| SQLite for tests vs PostgreSQL in prod | Schema drift risk | Open |
| No formal release process | Manual deploys | Open |
| Dokploy config external to repo | Env drift | Open |

---

## Priority Ranking (Current Manual Promotion Order)

This ranking applies to the post-Spec-310 productization sequence. If a target already has an older spec package, treat the item as a refresh/execution follow-through only when current repo truth still leaves the product gap open.

Parallel immediate guardrail lane: the Cross-Domain Progress / Indicator Semantics candidate group in `docs/product/spec-candidates.md` should be promoted alongside OperationRun maturity when UI semantic drift is the active concern. Spec 278 provides the audit inventory and standards-delta input; the remaining follow-up remains split across contract, component, quality-gate, and migration lanes. It stays outside the main sellability ordering below because it is a cross-cutting semantics and standards package rather than a standalone customer-facing delivery lane.

Parallel immediate repair lane: the Admin Workspace Navigation & Tenant-owned Surface Repair candidate group in `docs/product/spec-candidates.md` is now mostly historical sequencing context after Specs 301-304. Promote only `navigation-contract-split`, and only when fresh repo evidence shows residual shared-contract drift between workspace-home cleanliness and environment-bound admin visibility.

1. Customer Review Workspace v1 Completion
2. Localization v1 Customer-facing Surfaces
3. Decision-Based Governance Inbox v1
4. Commercial Entitlements / Billing-State Maturity
5. Cross-Tenant Compare & Promotion Execution
6. Governance Artifact Lifecycle & Retention
7. External Support Desk / PSA Handoff
8. Private AI Execution Governance Foundation

---

## How to use this file

- **Big product and operating themes** live here.
- **Concrete spec candidates** → see `docs/product/spec-candidates.md`
- **Lifecycle / deletion / retention work must be taxonomy-first**: do not promote narrow ghost-policy, workspace deletion, tenant deletion, purge, or retention specs until the shared Workspace, Tenant & Managed Object Lifecycle Governance candidate defines the platform semantics.
- **Company automation / solo-founder operating items** live here as strategic tracks first; only product-impacting or repeatable engineering work should become spec candidates.
- **Solo-founder guardrails** should remain visible even when they are not immediate product specs, because they define what must become measurable, controllable, delegable, or documented before customer volume grows.
- **Governance positioning is Microsoft-first, provider-extensible**: roadmap language should keep the initial product scope focused on Microsoft tenant governance while avoiding unnecessary Microsoft-only coupling in platform-level abstractions.
- **AI positioning is local/private-first and provider-adapter-based**: roadmap language should avoid direct feature-level public AI calls and instead route AI through use-case registries, data classification, context builders, policy gates, budget gates, provider adapters, audit trails, and human approval workflows.
- **Small discoveries from implementation** → see `docs/product/discoveries.md`
- **Product principles** → see `docs/product/principles.md`
