Reference Stack and Exit
A reference stack shows how the parts of Sovereign Source AI fit together. No single product is required. The stack shows governed execution, and it shows that the institution keeps control. The stack passes if the organization can replace providers, move runtimes, and continue critical operations. During these changes, the organization must keep its intent, knowledge, authority, and evidence.
Reference build
The seven layers map to components with separate responsibilities:
| Layer | Reference components and roles |
|---|---|
| Intent | Typed intent registry, requirements, experience contracts, and an SSIL interpreter or compiler |
| Governance | Institutional identity, authority records, external policy gates, classifications, and approvals |
| Decision | Router for deterministic rules, statistical models, bounded models, reasoning models, and humans |
| Capability | Skill registry, declared operation contracts, permission checks, and authenticated tool access |
| Execution | Durable workflows, work orders, isolated workers, services, and deployment definitions |
| Verification | Tests, evaluations, security analysis, requirement checks, release gates, and outcome measurement |
| Evidence | Provenance relationships, component inventories, artifacts, attestations, audit records, and historical outcomes |
The ontology connects these components through shared institutional objects. Interfaces show those objects and their authorized actions. Storage keeps current state and historical evidence. The institution’s rules do not live only in the interface or in a model provider.
The four durable planes cover the whole stack:
- Intention sets the purpose.
- Governance limits actions.
- Verification checks results.
- Evidence keeps what the institution can reconstruct.
Together they support the loop Intent → Decide → Constrain → Execute → Verify → Prove.
Seven sovereignty tests
The manifesto’s seven questions become concrete tests of the reference architecture:
- Can the primary vendor be replaced without rebuilding the institution? Contracts, ontology definitions, policies, workflows, and evidence stay usable outside that vendor’s application.
- Can the runtime move to another environment? Execution definitions, dependencies, state, and policy boundaries stay valid in the destination environment.
- Can the organization retain and reconstruct its data and knowledge? Exported records keep relationships, history, source material, and the context of each derivation.
- Can agent permissions and actions be inspected? Work orders identify authorized capabilities, applicable policy, approvals, and recorded actions.
- Can models be swapped without rewriting business logic? Typed contracts and the router keep institutional rules separate from the behavior of a specific provider.
- Can critical functions operate privately or in restricted networks? Required models, dependencies, authorization, and evidence services stay available inside the permitted boundary.
- Does the organization retain identity, keys, policy, authorization, provenance, and audit? The organization keeps control of these functions after the provider contract ends.
A documented export feature is only part of the answer. The institution must also show evidence that its operations can continue on the exported material.
Replacement paths
You can replace a part if its adapter keeps the same definitions for the institution. You can change one part and keep the records that depend on it:
- Change the model adapter. The decision contracts stay the same.
- Change the workflow engine. The work orders and authority stay the same.
- Change the analytics service. The experience definitions and historical evidence stay the same.
Exit also depends on permissions and practical access. Source code is not enough without operational state, usable dependencies, keys, and deployment definitions. You must be able to move the whole governed system and its knowledge, not only the code.
Product layers
The product structure puts these responsibilities into six parts:
- a Sovereign Core
- an Agent and Capability Control Plane
- a Software Factory
- a Data and Evidence Platform
- an Enterprise Bridge
- vertical applications
The core holds ontology, authority, intent, policy, and evidence. The control plane governs models and capabilities. The factory makes verified artifacts. The data platform keeps state and history. Enterprise bridges connect the systems that the organization already has. Vertical products adapt the shared architecture for specific domains.
Commercial services can supply any of these components. Each service must let you examine it. It must use portable contracts, and you must be able to replace it.
From the research
- “The goal is credible exit and retained control.” Manifesto
- The ontology, policy, evidence, and intent models must stay the same when the implementation changes. Master summary
- The research separates architectural targets from completed implementations. The narrower reference slice showed persisted work and a guarded planner. Master summary