The roadmap starts from the system that exists.
Accounts, workspaces, desired state, product workflows, and received operational evidence.
Trust Console enrollment, launcher coordination, agent supervision, managed gateway, cache, and local evidence.
infraveil.json defines supported services, routes, health behavior, restart limits, order, and persistence.
Vendor release signatures and customer exact-hash approval under manual, allowlist, or auto policy.
Application output, runtime diagnostics, request and control traces, incidents, catalog and derived status, capacity diagnostics, cache and queue views, and fleet controls. Workspace-scoped MCP tools expose supported inspection and operating actions through authorization and preview/apply checks.
This chapter does not publish a completed request-bearing Validation Protocol run; scoped checks and implementation review have narrower evidence boundaries.
Expand authority only with matching controls.
- Define the boundary first. State what runs where, which data crosses it, and which customer responsibility remains.
- Keep authority explicit. New actions need a target, permission path, policy, stop condition, receipt, and recovery behavior.
- Separate state labels. Running, healthy, reachable, current, approved, and recovered remain distinct.
- Require observed evidence. Architecture and source review are prerequisites; a dated run establishes behavior for a particular build and environment.
- Preserve exit paths. Customers need documented custody, exports, revocation, local cleanup, persistent-data handling, and offboarding responsibilities.
Work is gated by evidence, not by narrative.
| Stage | Focus | Exit evidence | Status |
|---|---|---|---|
| 1 | Publish a reproducible Validation Protocol result for an identified build. | Request-bearing run manifest, raw outputs, fault timeline, and reviewed gaps. | Planned protocol publication; no completed run published in this chapter |
| 2 | Tighten installation, custody-mode transitions, persistence documentation, and offboarding. | Versioned docs, clean-host tests, mode-transition tests, and path inventory. | Planned |
| 3 | Improve correlation among desired state, approval, execution, health, gateway, and recovery records. | End-to-end identity coverage and documented missing-event behavior. | Planned |
| 4 | Expand supported policies or remediation classes only where rollback and stop conditions are defined. | Adversarial tests, bounded permissions, receipts, and failure drills. | Conditional direction |
Later work remains conditional.
Evaluate finer role boundaries, identity-provider integration, and exportable audit context against customer requirements.
Evaluate regional, private, or disconnected models without describing them as currently available.
Evaluate retention, residency, redaction, deletion, and support-access controls for defined offerings.
Define measurable service and recovery targets only when architecture, operations, and contractual remedies support them.
Add external systems when they reduce manual translation and preserve a clear source of operational truth.
Extend the supported MCP tool set only with explicit scope, authorization, preview/apply binding, stop conditions, and customer-visible results. Existing MCP operations are current; unrestricted shells, release-signing authority for a model, and retired built-in AI auto-healing are not the baseline.
Direction is not availability.
This roadmap does not promise universal fine-grained RBAC, SSO/SCIM, SOC 2 certification, a full air gap, a self-hosted management plane, data residency, a particular regional topology, an SLA, a delivery date, replacement of every adjacent tool, or a defined business outcome. Current documentation and signed agreements govern available capabilities.