Sovereignty is incomplete
without execution control.
Controlling which models run, and where they run, does not by itself control what those systems are permitted to execute. Execution authority is a separate control, and it can be held inside the boundary.
Model, compute and execution sovereignty
Model sovereigntyCompute sovereigntyExecution sovereignty
The same kernel.
With the network taken away.
The deployment profile changes where enforcement runs, who signs policy and who holds the evidence. It does not change the control contract.
The same proposal against the same policy state reproduces the same verdict. A record that has been altered fails chain verification.
- 01Signed local policy bundles
- 02Ed25519 signature verification
- 03Signing key outside the protected environment
- 04No required external control plane
- 05No required cloud database
- 06No required network
- 07Local evidence generation
- 08Local evidence rendering
- 09Fail-closed operation
- 10Tamper refusal
- 11Customer-controlled execution authority
- 12Customer-controlled evidence custody
- 13Isolated deployment
- 14Sovereign deployment profile
- 15Air-gapped operation
Acceptance-testable.
Not yet field-validated.
Verified in CI
- 01External network access removed during sovereign CI execution.
- 02Signed local policy bundles enforced without a database, control plane or network connection.
- 03Offline-clean interface with zero required external fonts, analytics, embeds or telemetry loads.
- 04Governance evidence, attestations and control mappings generated locally.
- 05Tampered policy bundles fail closed and load zero active policies.
- 06Acceptance tooling verifies a live unauthorised action and its resulting evidence chain.
Not done yet
- 01No deployment has run on customer hardware yet. The install media, images and acceptance suite exist; a witnessed site record does not.
- 02No third-party accreditation. No Common Criteria evaluation, no NCSC assurance, no FedRAMP authorisation, no ATO.
- 03No independent penetration test of the codebase has been commissioned.
- 04No identity provider of our own — Guardian OS sits behind the estate's existing IdP.
Guardian OS Sovereign is acceptance-testable, not field-validated. Everything in the left column is enforced by code and asserted by a test in CI. Everything in the right column is work that has not been done. No accreditation is claimed until one is held.
Institutions that must retain
control of how AI operates.
Configure a platform that exists,
or build one first.
The figures below are illustrative rather than quoted programme costs. Actual investment varies materially by scope, accreditation, deployment boundary and organisation size.
| Capability | Build internally | Guardian OS |
|---|---|---|
| Time to capability | 2–4 year platform programme | Platform available today |
| Illustrative engineering investment | £5M–£30M+ depending on scope and organisation size | Configure and integrate an existing platform |
| Governance kernel | Build, validate and maintain internally | Runtime Governance kernel already implemented |
| Specialist capability | Recruit and retain specialist engineering teams | Existing platform plus configuration and integration |
| Operating responsibility | Ongoing platform ownership and redevelopment | Ongoing platform operation, policy configuration and assurance |
This compares a multi-year internal platform programme with configuring an existing governed operating architecture. It is not a guaranteed savings claim.
Mission domains
without a second platform.
Sovereign Intelligence Packs add domain policies, workflows, evidence mappings and reporting structures while preserving one Runtime Governance kernel.