docs: realign product roadmap

This commit is contained in:
Ahmed Darrazi 2026-05-02 02:36:42 +02:00
parent 38a2cec475
commit b772cf634a

View File

@ -1,15 +1,15 @@
# Product Roadmap
> **Status:** Active
> **Last reviewed:** 2026-04-30
> **Last reviewed:** 2026-05-02
> **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-01 lifecycle/provider-missing wording alignment only; no full roadmap re-review was performed.
> **Scoped maintenance:** 2026-05-02 repo-based roadmap drift correction and queue/backlog alignment after the audit-derived product-truth review.
>
> Strategic thematic blocks and release trajectory.
> This is the "big picture" — not individual specs.
>
> Queue boundary: the active candidate queue lives in `spec-candidates.md`; older audit-derived candidate packages are historical inputs only.
> 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.
---
@ -28,18 +28,23 @@ ## Current Productization & Moat Priorities
| Order | Theme | Repo truth | Product posture | Why now | Candidate posture |
|---|---|---|---|---|---|
| 1 | Customer Review Workspace Productization v1 | Reviews, Evidence Snapshots, Review Packs, Customer Review Workspace, and accepted-risk foundations are repo-real | fast sellable | clearest sellability blocker between current repo truth and a customer-safe governance-of-record surface | active P0 candidate |
| 2 | Risk Acceptance & Accountability productization | Exception / risk-acceptance workflow is repo-verified, but customer-safe accountability presentation is not fully productized | fast sellable | strong MSP and German midmarket moat around documented decisions, expiry, reviewability, and audit trail | fold into Customer Review Workspace Productization and review/reporting follow-through, not a new greenfield foundation |
| 3 | Governance Decision Surface Convergence | Governance Inbox, My Findings, Intake, and Exception Queue are repo-real, but convergence is not | almost | reduces admin-tool sprawl and turns multiple queue surfaces into calmer decision work | active P1 candidate |
| 4 | Compliance Evidence Mapping v1 | Canonical controls, evidence, stored reports, reviews, and findings foundations are repo-real; customer-safe compliance mapping is not | foundation-only | strong governance moat for compliance-oriented MSP and Mittelstand reviews without certification claims | active P2 candidate |
| 5 | Governance-as-a-Service Packaging v1 | Review packs, exports, evidence, and accepted-risk foundations are repo-real; recurring executive/MSP packaging is not | foundation-only | turns governance truth into a repeatable MSP deliverable instead of one-off manual reporting | active P2 candidate |
| 6 | Cross-Tenant Compare & Promotion v1 | Portfolio triage exists; compare and promotion are not repo-proven | not implemented | strongest MSP multiplier after customer-safe review and decision workflows are calmer | active P1 candidate |
| 7 | Private AI Execution Governance Foundation | Spec 248 exists, but no repo-real governed AI execution layer is proven | only spec / not implemented | strategic moat later, but not ahead of current productization and portfolio-action gaps | keep as later strategic lane, not near-term blocker |
| 1 | Auditor Pack Delivery & Executive Export v1 | Review-pack export, evidence, tenant review, customer review productization, compliance mapping, and governance packaging foundations are already spec-backed and partially repo-real | fast sellable | clearest remaining step between repo-real governance truth and auditor-/executive-ready delivery | manual promotion only, not auto-prep |
| 2 | Customer Review Workspace Productization v1 | Reviews, Evidence Snapshots, Review Packs, Customer Review Workspace, and accepted-risk foundations are repo-real | fast sellable | clearest customer-safe governance-of-record surface gap | spec-backed follow-through, not active queue |
| 3 | Governance Decision Surface Convergence | Governance Inbox, My Findings, Intake, and Exception Queue are repo-real, but convergence remains incomplete | implemented but not productized | reduces admin-tool sprawl and turns multiple queue surfaces into calmer decision work | spec-backed follow-through, not active queue |
| 4 | Compliance Evidence Mapping v1 | Canonical controls, evidence, stored reports, reviews, and findings foundations are repo-real; customer-safe compliance mapping follow-through remains | implemented but not productized | strong governance moat for compliance-oriented MSP and Mittelstand reviews without certification claims | spec-backed follow-through, not active queue |
| 5 | Governance-as-a-Service Packaging v1 | Review packs, exports, evidence, and accepted-risk foundations are repo-real; recurring executive/MSP packaging follow-through remains | implemented but not productized | turns governance truth into a repeatable MSP deliverable instead of one-off manual reporting | spec-backed follow-through, not active queue |
| 6 | Cross-Tenant Promotion Execution v1 | Cross-tenant compare preview and promotion preflight are repo-real; execution is not | not implemented | strongest MSP multiplier after review and packaging lanes are calmer | manual promotion only, not auto-prep |
| 7 | Governance Decision Pack & Approval Workflow v1 | Decision convergence and decision-based operating framing are strong enough for a bounded human-in-the-loop slice, but the workflow itself is not implemented | not implemented | next narrow decision workflow without autonomous remediation | manual promotion only, not auto-prep |
| 8 | Customer-Facing Localization Adoption v1 | Locale foundation is repo-real; customer-facing adoption, glossary completion, and regression hardening remain | implemented but not productized | turns existing localization groundwork into customer-safe polish | manual promotion only, not auto-prep |
| 9 | Billing & Subscription Truth Layer v1 | Plans, entitlements, and commercial lifecycle are repo-real; billing/subscription truth is not | not implemented | closes the remaining commercial truth gap | manual promotion only, not auto-prep |
| 10 | Stored Reports Surface v1 | Stored-report substrate is repo-real through evidence and review foundations; product surface remains incomplete | foundation-only | makes retained governance artifacts usable without manual digging | manual promotion only, not auto-prep |
| 11 | First Governed AI Runtime Consumer v1 | Governed AI policy foundation is repo-real; no first governed runtime consumer is proven | not implemented | bounded post-foundation AI adoption after higher-priority sellability gaps | manual promotion only, not auto-prep |
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 private AI as a fresh roadmap idea; the foundation already exists at spec level and should remain behind current customer-facing and MSP-facing sellability gaps.
- 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.
---
@ -92,7 +97,7 @@ ### R1.9 Platform Localization v1 (DE/EN)
- 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**: no standalone active candidate right now; remaining localization work should be folded into customer-facing productization and UI-maturity follow-through unless a narrower repo-real gap emerges.
**Queue status**: no standalone active candidate right now; the historical foundation package is `specs/252-platform-localization-v1/spec.md`, and the remaining follow-through is `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.
@ -107,7 +112,7 @@ ### Product Scalability & Self-Service Foundation
- 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
**Active specs**: — (not yet specced)
**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`.
---
@ -137,11 +142,12 @@ ### R1.x Foundation Hardening — Governance Platform Anti-Drift
- No AWS/GCP/SaaS connector implementation in this slice; this is anti-drift foundation work only
### R2 Completion — Evidence & Exception Workflows
- Review pack export (Spec 109 — done)
- 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 → Spec 153 (evidence snapshots, draft) + Spec 155 (tenant review layer / review packs, draft)
- 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 → sharpen customer-facing review consumption: baseline status, latest reviews, findings, accepted risks, evidence/review-pack downloads, customer-safe redaction, calmer access states, and no admin/remediation actions
- 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
@ -168,13 +174,13 @@ ### Workspace, Tenant & Managed Object Lifecycle Governance
- 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**: Strategic P2 enterprise-trust candidate, not immediate implementation. This should not block Customer Review Workspace Productization, Governance Decision Surface Convergence, or Cross-Tenant Compare & Promotion.
**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 candidate**: `Workspace, Tenant & Managed Object Lifecycle Governance v1` in `docs/product/spec-candidates.md`.
**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)
@ -228,6 +234,7 @@ ### Product Usage, Customer Health & Operational Controls
### 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.
@ -364,7 +371,7 @@ ## 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, Spec 043 draft.
**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.
@ -388,12 +395,14 @@ ## Infrastructure & Platform Debt
| 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 |
| 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 formal security trust pack yet | Enterprise sales and customer security reviews require repeated manual explanations | Covered by Solo-Founder SaaS Automation & Operating Readiness |
| No product usage/adoption telemetry yet | Founder cannot see onboarding drop-off, feature adoption, trial health, or support-triggering surfaces without manual investigation | Covered by Additional Solo-Founder Scale Guardrails |
| No customer health score yet | Churn, inactive customers, stale reviews, unhealthy provider connections, and unresolved high-risk findings may be noticed too late | Covered by Additional Solo-Founder Scale Guardrails |
| No explicit operational controls / feature flags lane | Incidents or risky features may require code changes or manual database intervention instead of safe operator controls | Covered by Additional Solo-Founder Scale Guardrails |
| No private AI execution foundation yet | Future AI features may call model providers directly, leak tenant context, become hard to audit, or require rewrites to support local/private models | Covered by Private AI Execution Governance Foundation |
| No AI usage budgeting / cost governance yet | AI-assisted summaries, decision packs, reviews, and support workflows may create uncontrolled compute/API costs and queue pressure | Covered by Private AI Execution Governance Foundation |
| No AI data classification / context-builder boundary yet | Raw provider payloads, personal data, or customer-confidential tenant context could be over-shared with models instead of sanitized purpose-specific context | Covered by Private AI Execution Governance Foundation |
| Auditor-ready executive export is not yet productized | Review truth still stops short of auditor-/executive-ready delivery without additional packaging | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
| Cross-tenant promotion execution is missing | Compare preview and preflight stop short of the actual portfolio action | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
| Governance decision pack and approval workflow is missing | Decision-based operating still lacks a bounded approval-ready action package with explicit audit trail | Covered by the manual-promotion backlog 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 |
@ -406,31 +415,27 @@ ## Infrastructure & Platform Debt
---
## Priority Ranking (from Product Brainstorming)
## Priority Ranking (Current Manual Promotion Order)
1. Product Scalability & Self-Service Foundation
2. Product Usage, Customer Health & Operational Controls
3. Private AI Execution Governance Foundation
4. Decision-Based Operating / Governance Inbox
5. MSP Portfolio + Alerting
6. Drift + Approval Workflows
7. Evidence / Review Packs + Customer Review Workspace
8. Standardization / Linting
9. Promotion DEV→PROD
10. Recovery Confidence
11. Solo-Founder SaaS Automation & Operating Readiness
12. Additional Solo-Founder Scale Guardrails
1. Auditor Pack Delivery & Executive Export v1
2. Cross-Tenant Promotion Execution v1
3. Governance Decision Pack & Approval Workflow v1
4. Customer-Facing Localization Adoption v1
5. Billing & Subscription Truth Layer v1
6. Stored Reports Surface v1
7. Workspace & Tenant Closure Lifecycle v1
8. First Governed AI Runtime Consumer v1
---
## How to use this file
- **Big product and operating themes** live here.
- **Concrete spec candidates** → see [spec-candidates.md](spec-candidates.md)
- **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 [discoveries.md](discoveries.md)
- **Product principles** → see [principles.md](principles.md)
- **Small discoveries from implementation** → see `docs/product/discoveries.md`
- **Product principles** → see `docs/product/principles.md`