diff --git a/docs/roadmaps/not-started/platform_AGENT_PLATFORM_GAP_ROADMAP_INDEX.md b/docs/roadmaps/not-started/platform_AGENT_PLATFORM_GAP_ROADMAP_INDEX.md index 4b050245..b0c8a3cc 100644 --- a/docs/roadmaps/not-started/platform_AGENT_PLATFORM_GAP_ROADMAP_INDEX.md +++ b/docs/roadmaps/not-started/platform_AGENT_PLATFORM_GAP_ROADMAP_INDEX.md @@ -34,6 +34,25 @@ can be sequenced without mixing concerns. --- +## Default Platform Decisions + +To make the roadmap executable, these should be treated as the default assumptions +unless a later ADR explicitly changes them: + +- **Control plane remains in `platform-service`.** +- **`mcp-server` remains an execution and tooling surface, not the system of record.** +- **`@bytelyst/queue` remains the immediate job primitive.** +- **Redis is the first new infrastructure dependency to add** for durable eventing, + coordination, leases, and future worker scale-out. +- **Do not introduce Temporal in v1.** Design for Temporal compatibility, but do not + pay the operational cost before the platform proves it needs workflow-native semantics. +- **Do not force all new domains into Cosmos.** Relational domains should be allowed to + move to PostgreSQL when they become awkward or risky in document storage. +- **Human review, governance, and budget controls are mandatory platform capabilities,** + not optional product features. + +--- + ## Roadmap Set 1. [Agent Runtime & Orchestration Roadmap](./platform_AGENT_RUNTIME_ORCHESTRATION_ROADMAP.md) @@ -90,6 +109,44 @@ foundations and the missing layers: --- +## Dependency Graph + +The ten roadmaps are not independent. The strongest sequencing is: + +1. **Durable Event Bus & Worker Runtime** + This provides the durable execution substrate for the rest. +2. **Agent Runtime & Orchestration** + Depends on durable workers and queue conventions. +3. **Org, Workspace & RBAC** + Required before tenant-safe approval, retrieval, and enterprise provisioning. +4. **Human Review & Approval Queue** + Depends on agent runs and tenant boundaries. +5. **Agent Registry & Prompt Versioning** + Depends on agent runs for production traceability and on governance for release gates. +6. **AI Governance & Evaluation** + Depends on registry/versioning to attach decisions to concrete artifacts. +7. **AI Budget & Cost Governance** + Depends on tenant model and run/request attribution. +8. **Knowledge & RAG Service** + Depends on tenant boundaries for safe retrieval. +9. **Enterprise Provisioning & SCIM** + Depends on org/workspace/team model. +10. **Support Case Management** + Depends on runs, reviews, tenanting, and diagnostics links to be genuinely useful. + +--- + +## Success Criteria For The Roadmap Set + +This roadmap family should be considered successful only when it produces: + +- a clear execution order rather than ten disconnected ideas +- a default architecture stance for this repo +- explicit separation between **best industry-standard stack** and **best immediate fit** +- enough detail to derive implementation epics without rewriting the docs from scratch + +--- + ## Architectural Guidance These docs assume the current repo direction remains: @@ -104,6 +161,8 @@ than the current Cosmos-first platform modules. Each roadmap therefore includes: - a **recommended stack** for long-term quality - a **repo-fit alternative** that stays closer to current conventions +- a **default decision for this repo now** +- explicit **dependencies** and **v1 non-goals** That is intentional. The best industry-standard choice is not always the same as the least disruptive repo-local choice. diff --git a/docs/roadmaps/not-started/platform_AGENT_REGISTRY_PROMPT_VERSIONING_ROADMAP.md b/docs/roadmaps/not-started/platform_AGENT_REGISTRY_PROMPT_VERSIONING_ROADMAP.md index 3dbdd92c..82d34837 100644 --- a/docs/roadmaps/not-started/platform_AGENT_REGISTRY_PROMPT_VERSIONING_ROADMAP.md +++ b/docs/roadmaps/not-started/platform_AGENT_REGISTRY_PROMPT_VERSIONING_ROADMAP.md @@ -31,6 +31,27 @@ and docs rather than treated as versioned platform data. - Prompt artifacts stored in blob storage - MCP server resolves active versions from `platform-service` +### Default Decision For This Repo + +- Put the system of record in `platform-service` +- Store large prompt assets in blob storage +- Require `agentVersion` and `promptVersion` on every durable run + +--- + +## Dependencies + +- Agent Runtime & Orchestration +- AI Governance & Evaluation + +--- + +## V1 Non-Goals + +- Non-technical prompt editing UI +- Marketplace-style public agent publishing +- Full GitOps-only release flow + --- ## Phase 1 - Core Registry diff --git a/docs/roadmaps/not-started/platform_AGENT_RUNTIME_ORCHESTRATION_ROADMAP.md b/docs/roadmaps/not-started/platform_AGENT_RUNTIME_ORCHESTRATION_ROADMAP.md index a5e9a1db..f1c72c8a 100644 --- a/docs/roadmaps/not-started/platform_AGENT_RUNTIME_ORCHESTRATION_ROADMAP.md +++ b/docs/roadmaps/not-started/platform_AGENT_RUNTIME_ORCHESTRATION_ROADMAP.md @@ -47,6 +47,30 @@ That is enough for prototypes. It is not enough for: Start with the repo-fit option to get durable runs quickly, but design the run model so a later move to Temporal is possible without rewriting every agent contract. +### Default Decision For This Repo + +- Build v1 in `platform-service` +- Use `@bytelyst/queue` as the execution primitive +- Use Redis later for leases and distributed coordination +- Keep `mcp-server` as a client/executor, not the run system of record + +--- + +## Dependencies + +- Durable Event Bus & Worker Runtime +- Human Review & Approval Queue +- Agent Registry & Prompt Versioning + +--- + +## V1 Non-Goals + +- Full Temporal adoption +- Visual workflow builders +- Arbitrary user-authored workflow DSLs +- Multi-region active-active workflow execution + --- ## Phase 1 - Canonical Run Model diff --git a/docs/roadmaps/not-started/platform_AI_BUDGET_COST_GOVERNANCE_ROADMAP.md b/docs/roadmaps/not-started/platform_AI_BUDGET_COST_GOVERNANCE_ROADMAP.md index 58aa8412..cb42cb91 100644 --- a/docs/roadmaps/not-started/platform_AI_BUDGET_COST_GOVERNANCE_ROADMAP.md +++ b/docs/roadmaps/not-started/platform_AI_BUDGET_COST_GOVERNANCE_ROADMAP.md @@ -38,6 +38,27 @@ The repo has usage and billing modules, but not a dedicated AI cost governance l This fits naturally in `platform-service`. The key is not the datastore; it is the quality of attribution and enforcement. +### Default Decision For This Repo + +- Implement this inside `platform-service` +- Treat run/request attribution as mandatory +- Make budget checks part of the request path for expensive AI calls, not reporting-only + +--- + +## Dependencies + +- Org, Workspace & RBAC +- Agent Runtime & Orchestration + +--- + +## V1 Non-Goals + +- Full finance ERP integration +- Provider contract optimization tooling +- Perfect real-time cost accuracy across every vendor + --- ## Phase 1 - Usage Ledger diff --git a/docs/roadmaps/not-started/platform_AI_GOVERNANCE_EVALS_ROADMAP.md b/docs/roadmaps/not-started/platform_AI_GOVERNANCE_EVALS_ROADMAP.md index 56d789de..3d061b18 100644 --- a/docs/roadmaps/not-started/platform_AI_GOVERNANCE_EVALS_ROADMAP.md +++ b/docs/roadmaps/not-started/platform_AI_GOVERNANCE_EVALS_ROADMAP.md @@ -36,6 +36,27 @@ What it does not have is a central AI governance surface that answers: - Promptfoo or a similar eval harness for offline regression - policy layer using code-first rules first, with optional Cedar or OPA later +### Default Decision For This Repo + +- Use Promptfoo-style offline evals first +- Keep policy enforcement in platform code before introducing a separate policy runtime +- Require governance links to agent and prompt versions rather than free-floating eval runs + +--- + +## Dependencies + +- Agent Registry & Prompt Versioning +- Agent Runtime & Orchestration + +--- + +## V1 Non-Goals + +- Universal automated red-teaming +- Full legal/compliance policy engine +- Replacing feature flags or experiments + --- ## Phase 1 - Eval Registry diff --git a/docs/roadmaps/not-started/platform_DURABLE_EVENT_BUS_AND_WORKER_RUNTIME_ROADMAP.md b/docs/roadmaps/not-started/platform_DURABLE_EVENT_BUS_AND_WORKER_RUNTIME_ROADMAP.md index de27a2f8..f3d86c6b 100644 --- a/docs/roadmaps/not-started/platform_DURABLE_EVENT_BUS_AND_WORKER_RUNTIME_ROADMAP.md +++ b/docs/roadmaps/not-started/platform_DURABLE_EVENT_BUS_AND_WORKER_RUNTIME_ROADMAP.md @@ -46,6 +46,28 @@ layer is still incomplete. Use `@bytelyst/events` as the interface, but add a durable Redis or NATS adapter. Do not let direct in-memory emitters remain the production default for critical flows. +### Default Decision For This Repo + +- Keep `@bytelyst/events` as the public interface +- Add Redis-backed durability first +- Keep memory adapters for tests only +- Standardize worker bootstrap across services before adding more background features + +--- + +## Dependencies + +- None for the core substrate +- Required by Agent Runtime, Delivery side effects, and future SCIM sync jobs + +--- + +## V1 Non-Goals + +- Kafka-scale event streaming +- Exactly-once delivery guarantees +- Cross-region event replication + --- ## Phase 1 - Event Abstraction diff --git a/docs/roadmaps/not-started/platform_ENTERPRISE_PROVISIONING_SCIM_ROADMAP.md b/docs/roadmaps/not-started/platform_ENTERPRISE_PROVISIONING_SCIM_ROADMAP.md index 0b7df308..30174f70 100644 --- a/docs/roadmaps/not-started/platform_ENTERPRISE_PROVISIONING_SCIM_ROADMAP.md +++ b/docs/roadmaps/not-started/platform_ENTERPRISE_PROVISIONING_SCIM_ROADMAP.md @@ -31,6 +31,27 @@ It does not solve enterprise lifecycle management: - org/workspace mapping from the tenant model - optional background sync jobs using `@bytelyst/queue` +### Default Decision For This Repo + +- Keep enterprise provisioning in `platform-service` +- Implement SCIM only after org/workspace/team exists +- Use queued reconciliation jobs for drift repair and large sync batches + +--- + +## Dependencies + +- Org, Workspace & RBAC +- Durable Event Bus & Worker Runtime + +--- + +## V1 Non-Goals + +- Supporting every optional SCIM feature extension +- Bi-directional identity sync with every enterprise system +- Full HRIS integration + --- ## Phase 1 - SCIM Foundations diff --git a/docs/roadmaps/not-started/platform_HUMAN_REVIEW_APPROVAL_QUEUE_ROADMAP.md b/docs/roadmaps/not-started/platform_HUMAN_REVIEW_APPROVAL_QUEUE_ROADMAP.md index ca81cbef..417c41e9 100644 --- a/docs/roadmaps/not-started/platform_HUMAN_REVIEW_APPROVAL_QUEUE_ROADMAP.md +++ b/docs/roadmaps/not-started/platform_HUMAN_REVIEW_APPROVAL_QUEUE_ROADMAP.md @@ -31,6 +31,27 @@ also needs a generic review queue for cases like: - Slack and Telegram delivery adapters for reviewer notifications - Optional policy engine later with OpenFGA or Cedar +### Default Decision For This Repo + +- Build this inside `platform-service` +- Use agent-run state transitions rather than bespoke approval callbacks per feature +- Reuse existing delivery channels for reviewer notification fan-out + +--- + +## Dependencies + +- Agent Runtime & Orchestration +- Org, Workspace & RBAC + +--- + +## V1 Non-Goals + +- Full BPM suite +- Arbitrary multi-stage approval designers +- End-user-facing case portals + --- ## Phase 1 - Review Objects diff --git a/docs/roadmaps/not-started/platform_KNOWLEDGE_RAG_SERVICE_ROADMAP.md b/docs/roadmaps/not-started/platform_KNOWLEDGE_RAG_SERVICE_ROADMAP.md index 88810cb0..50b65c83 100644 --- a/docs/roadmaps/not-started/platform_KNOWLEDGE_RAG_SERVICE_ROADMAP.md +++ b/docs/roadmaps/not-started/platform_KNOWLEDGE_RAG_SERVICE_ROADMAP.md @@ -47,6 +47,27 @@ Use PostgreSQL + pgvector if you want the strongest balance of flexibility, ownership, and industry-standard retrieval patterns. Azure AI Search is a valid alternative if deep Azure integration matters more than datastore simplicity. +### Default Decision For This Repo + +- Keep ingestion orchestration in `platform-service` +- Reuse `extraction-service` for parsing/chunk preparation where it makes sense +- Do not use Cosmos as the long-term primary RAG engine + +--- + +## Dependencies + +- Org, Workspace & RBAC +- AI Budget & Cost Governance + +--- + +## V1 Non-Goals + +- General web-scale crawling +- Training or fine-tuning custom foundation models +- Cross-tenant shared retrieval by default + --- ## Phase 1 - Knowledge Objects diff --git a/docs/roadmaps/not-started/platform_ORG_WORKSPACE_RBAC_ROADMAP.md b/docs/roadmaps/not-started/platform_ORG_WORKSPACE_RBAC_ROADMAP.md index 4b464650..bb641fcb 100644 --- a/docs/roadmaps/not-started/platform_ORG_WORKSPACE_RBAC_ROADMAP.md +++ b/docs/roadmaps/not-started/platform_ORG_WORKSPACE_RBAC_ROADMAP.md @@ -45,6 +45,28 @@ If tenanting will be central to the business, PostgreSQL is the better long-term fit because org/workspace membership is relational by nature. If short-term consistency matters more, start in Cosmos but keep the permission model portable. +### Default Decision For This Repo + +- Keep auth identity in `platform-service` +- Add org/workspace/team as first-class platform modules +- Start with service-level authorization helpers +- Reserve OpenFGA for phase 2+ if sharing rules become too rich for code-level RBAC + +--- + +## Dependencies + +- None for the first schema pass +- Required by Knowledge & RAG, Human Review, AI Budgets, and SCIM + +--- + +## V1 Non-Goals + +- Full ABAC across every existing module +- End-user custom roles +- Cross-product federation of every resource type on day one + --- ## Phase 1 - Data Model diff --git a/docs/roadmaps/not-started/platform_SUPPORT_CASE_MANAGEMENT_ROADMAP.md b/docs/roadmaps/not-started/platform_SUPPORT_CASE_MANAGEMENT_ROADMAP.md index 7d1bfaa1..6fa3a2a7 100644 --- a/docs/roadmaps/not-started/platform_SUPPORT_CASE_MANAGEMENT_ROADMAP.md +++ b/docs/roadmaps/not-started/platform_SUPPORT_CASE_MANAGEMENT_ROADMAP.md @@ -32,6 +32,28 @@ Without a case system, support work becomes fragmented across logs, chat, and ad This can live comfortably in `platform-service`. If the case domain becomes highly relational, PostgreSQL is better. Otherwise a Cosmos-backed module is acceptable. +### Default Decision For This Repo + +- Build the case system in `platform-service` +- Link cases directly to run IDs, review IDs, and diagnostics sessions +- Treat external helpdesk sync as secondary, not the system of record + +--- + +## Dependencies + +- Agent Runtime & Orchestration +- Human Review & Approval Queue +- Org, Workspace & RBAC + +--- + +## V1 Non-Goals + +- Full CRM replacement +- Multi-channel customer messaging inbox +- External vendor-specific support automation + --- ## Phase 1 - Core Case Model