One blueprint, many suppliers
The architecture is a shared blueprint, not a single product. Each layer is defined by open standards and open formats, so any qualified supplier, in the UK or among allies, can deliver it. That keeps the benefits of standardisation (common skills, reuse, interoperability) without creating a new dependency on one vendor.
It uses the same seven layer groups as the Body of Knowledge, so every component can be traced back to the evidence about where we are today.
Reference layers
| Layer | Sovereign approach | Open standards and examples |
|---|---|---|
| Identity & access | Federated identity with user control; UK-operated identity providers; passwordless by default | OAuth 2.0 and OpenID Connect, FIDO2/WebAuthn, SAML for federation; building on GOV.UK One Login, NHS Care Identity Service 2 and the UK Access Management Federation; Keycloak as an open identity server |
| Workplace | Open document formats; collaboration and file storage run by UK operators | Open Document Format (ODF), already a UK government standard; Nextcloud, Collabora Online and LibreOffice; open email and calendar standards (IMAP, CalDAV); Matrix for messaging |
| Data & integration | Data portable by default; row-level access control; published APIs | OpenAPI, GraphQL, JSON Schema; open table formats; FHIR and openEHR in health |
| AI | Models that can be inspected, pinned and hosted in the UK; no single model provider | Open-weight models served on UK infrastructure; ONNX for portability; open evaluation suites |
| Platform | Open runtimes and databases with foundation governance | Linux, PostgreSQL, Kubernetes and container standards; languages governed by foundations or standards bodies |
| Infrastructure | UK-operated cloud with customer-held keys; workloads portable between providers | Infrastructure as code; open object-storage APIs; multiple UK and allied operators |
| Physical | Diverse hardware supply; long-term open instruction sets | Arm-based devices today; RISC-V as the long-term open hardware path |
| Security | Customer-held keys, open telemetry, shared sector security operations | Hardware security modules under UK control; OpenTelemetry; shared SOCs such as Jisc’s |
Requirements at every layer
Whatever the layer, a component should meet the same sovereignty tests:
- UK operation. Run by UK-based, security-cleared staff where the risk warrants it.
- Customer-held keys. Encryption keys held by the public body, not the provider.
- Open formats and exit. Data exportable in open formats; exit tested, not assumed.
- Inspectable code. Open source, or source available to the customer for audit.
- Multiple suppliers. At least two credible suppliers able to deliver or support it.
Where to start
The order follows the evidence on where dependency is greatest and where change is least disruptive to users:
- Identity. It is the single point that every other service depends on, and the UK already has strong open assets to build on.
- File storage and collaboration. High dependency, open alternatives that are mature, and open document formats already mandated.
- Cloud operation. Move from UK-hosted to UK-operated, with customer-held keys.
- Desktop. Starting in schools and in organisations with simple estates, where the experience of the French Gendarmerie and Schleswig-Holstein shows what success requires. See what’s working.
Relationship to the white paper
The white paper sets out the original digital primitives proposal. This page updates it with the Body of Knowledge evidence, adds the workplace layer and makes control, not just location, the test of sovereignty.