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.
Runtime, incident, status, gateway, command, and recovery records with deployment-specific availability.
No successful request-bearing Validation Protocol record is currently published in the checked-in material.
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; no successful checked-in run yet |
| 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.
Add proposal or automation classes only with explicit permissions, policy, evidence, stop conditions, and customer-visible results.
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.