docs(roadmaps): refine agent platform roadmap decisions

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.

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

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

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

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

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

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

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

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

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

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