Developers / Architecture
One kernel, provider-neutral surfaces
Omnacta OS keeps a single authoritative mission kernel at the center. Clients, agents, models, and tools are provider-neutral surfaces around it — none of them hold a competing copy of mission truth.
The system-context diagram below reflects the currently deployed reference architecture. Deeper sequence diagrams describe target design and are labelled accordingly.
System context
How a visitor request reaches Omnacta Web today, generated from the same versioned diagram source used elsewhere on this site.
Visitors reach Omnacta Web through a CDN/edge layer, which routes to static content, the form API, analytics, and documentation.
- Visitor → CDN/Edge
- CDN/Edge → Omnacta Web
- Omnacta Web → Static Content
- Omnacta Web → Form API
- Omnacta Web → Analytics
- Omnacta Web → Documentation
Platform planes and their position in the mission lifecycle
Omnacta OS is composed of cooperating planes that share one mission lifecycle and one authoritative ledger. Each plane below states the position it occupies and its current maturity. Maturity is stated as text, never implied by ordering.
| Plane | Position in the shared lifecycle | Maturity |
|---|---|---|
| Omnacta Kernel | Owns mission transitions, execution, recovery, effects, and authoritative state. | In development |
| Omnacta Context | Supplies provenance-aware, minimum-sufficient intelligence to the plan and decision stages. Owns selection, summarisation, caching, and invalidation. | In development |
| Omnacta Evidence | Binds acceptance to scoped observations, evaluations, and proof. No client may author an acceptance decision. | In development |
| Omnacta Foundry | Packages and certifies agents, verifiers, workflows, integrations, and Mission Packs before they become selectable capabilities. | Planned |
| Omnacta Studio | Presents projections of authoritative state and submits versioned commands. It is a client, never a second orchestrator. | Vision |
| Mission Packs | Specialize one shared operating environment per professional domain. A descriptor never implies executable capability. | In development |
Omnacta GlassBox, the planned causal observability, verification, and control plane, is deliberately not described on this page. Its position in the shared mission lifecycle is published here only after its publication gate passes; that gate is currently open. Its absence is a governance decision, not an omission from the architecture.
Trust boundaries and threat assumptions
Each boundary below states what is and is not trusted across it, so integrators know exactly where their responsibility starts.
| Boundary | Assumption |
|---|---|
| Client ↔ Kernel | Clients (Studio, CLI, API/SDK) are untrusted for state; only the Kernel holds authoritative mission state. |
| Kernel ↔ Worker | Workers execute within leased, time-boxed, scope-limited authority; the Kernel does not trust a worker beyond its granted scope. |
| Kernel ↔ External systems | External effects require the highest authority level and pass through explicit approval or policy gates. |
| Evidence ↔ Verifier | A verifier is treated as independent only if it does not reuse the executing agent's own context or self-attestation. |
Versioning and compatibility
Four independent dimensions are versioned so a change in one does not silently break another.
Protocol version
Wire-level contract between clients and the Kernel; breaking changes are versioned explicitly.
Mission Pack version
Each pack declares a semantic version independent of the Kernel release.
Plan schema version
Persisted plans carry a schema version so older missions remain replayable.
Evidence format version
Proof objects are versioned so verifiers can reject or migrate older formats explicitly.
Deployment modes and maturity
- Local-first execution is the most mature deployment mode today.
- Private deployment (self-hosted Kernel) is a planned deployment target, not yet generally available.
- Managed cloud hosting is a planned deployment target, not yet generally available.
- Diagrams on this page are generated from versioned source and reviewed against the implementation they describe.
Continue to protocols
Protocols documents the wire-level contracts referenced by these trust boundaries.