Sovereign stack
Publishes the self-hostable reference deployment: container and orchestration packages for a spatially enabled relational database, the API, evaluators, scheduler, message broker and a static portal, with signed images and SBOMs, data residency and an air-gapped mode, so that a country or region can operate the standards on its own infrastructure. Each artefact of the area carries a UNI (Unique Nexus Identifier).
- Nexus Standards: NS-9, NS-11, NS-12.
- Open standards: OCI Image and Distribution Specifications; Sigstore (Cosign, Fulcio, Rekor); SPDX specification; Digital Public Goods Standard; OpenTelemetry specification.
- Data and feeds: endoflife.date API; Artifact Hub API; OSV.dev vulnerability API.
- Couples with: Sovereign deployment and data residency; Deployment services; Sovereign deployment pathway.
- Nexus Standards
- 3
- NS-9, NS-11, NS-12
- Open standards
- 5
- named, never copied
- Data and feeds
- 3
- listed for reference
- Couplings
- 3
- with other areas
- UNI
- requested · allocation in progress
- Status
- Proposednot yet in the catalogue
- Last reviewed
- area profile
Nexus Standards (2026). Sovereign stack: area brief, Open Infrastructure and Developers programme. Proposed. https://nexustandards.com/open-infrastructure/sovereign-stack/. Last reviewed 17 October 2026.
Files include the credits and the licence statement and are generated in the browser; no data is transmitted. Downloads require JavaScript.
Scope and boundaries
An area of the Open Infrastructure and Developers programme (infrastructure services). The area profile sets out 4 matters in scope and 2 matters addressed by other areas.
In scope 4
- Reference charts and images
- Residency defaults and federation peering
- Air-gap packaging with vendored schemas and digests
- Upgrade and rollback procedures
Out of scope 2
- Operating hosts for governments
- Proprietary cloud-only services
Jurisdictions Application in each jurisdiction is a national decision, taken by the National Standards Council (NSC) with the competent national authorities.
Foundation, referenced and implementing layers
The standards architecture of this context, from the foundation standards to the open standards referenced (grouped by type of relation) and the services and data sources that build on them.
The interactive view requires JavaScript; the sections below present the same records.
The service pipeline
A request reaches the service with an explicit context; inputs are identified (NS-1) and validated against OCI Image and Distribution Specifications; the service processes them and writes records with provenance; results are published, resolved and monitored, and a correction flows back through the same path. Nexus Standards applied: NS-9, NS-12, NS-11. 8 operations in 5 phases, built from the area profile: the rows carry its own data sources, indicators, open standards, couplings and, where listed, hazards, and each operation names the rules it implements (11). Records and artefacts are cited by UNI (Unique Nexus Identifier) and version.
Standards · codify and correct
Standard lifecycle
Standard lifecycle · NS-13 track · Contribution channels · IETF track · W3C track · OGC track · OASIS track · ISO and IEC stages · Conformance · Record lifecycle · Routing · Monitoring.
Cycle findings become change proposals, the Global Standards Council adopts after a public last call, and each country decides its own adoption.
01 Route missions
- 01Route missions to standards and profilesStep · Nexus StandardsNexus Standards routes each candidate mission to the standards and profiles that apply.
02 Profiles and conformance
- 02Compose mission profilesStep · Nexus StandardsNexus Standards composes mission profiles and records any national adoption the missions depend on.
- 03Validate build outputs against the profilesStep · Nexus StandardsNexus Standards validates build outputs against the composed profiles and records the evidence.
- 04Monitor conformance and record sealed evidenceStep · Nexus StandardsDuring Action Week Nexus Standards monitors conformance and logs deviations.
03 Proposals and review
- 05Deviations and corrections become change proposalsStep · Nexus StandardsDeviations become change proposals, and the correction is recorded as a change to the evidence.
- 06Cycle findings become change proposalsStep · Nexus StandardsFindings from a cycle become change proposals: method and correction findings from Reports (F06) and docket items from Nexus…
- 07Draft and revise in the openStep · Committees and working groupsTechnical committees and working groups draft and revise the standards in the open process of NS-13.
- 08Review toward a council decisionStep · Nexus StandardsNexus Standards moves change proposals through review toward a council decision.
04 Council decision
- 09Public last callStep · Global Standards CouncilThe Global Standards Council adopts by a two-thirds majority after a ninety-day last call.
- 10Global adoption of a standardDecision · Global Standards CouncilThe Global Standards Council decides the adoption of each standard after public last call.
05 Publish and identify
- 11Assign a UNI and publishStep · Secretariat (GCRI Canada)Nexus Standards assigns UNIs and deposits publications under the publisher’s process.
- 12A UNI identifies and never certifiesRecord · Nexus StandardsEvery object of the programme year carries one identifier, a UNI under NS-1, so that it can be cited, versioned and resolved.
- 13Publish the year’s adopted changesStep · Nexus StandardsAt renewal Nexus Standards publishes the year’s adopted changes and national adoption status.
06 National adoption and application
- 14National adoption by the National Standards CouncilDecision · National Standards CouncilEach country’s National Standards Council decides national adoption: adopt as is, adopt with a profile (NS-16), adapt, or reference only.
- 15Adopted standards reach courses and editionsStep · Nexus StandardsEach adopted standard or profile becomes a course module in Risk Academy (F09), and standards are applied in Reports editions (R1).
- 16Adoption is final for each jurisdictionStandard · National Standards CouncilAdoption is final for each jurisdiction, and the GSC has no veto over a national decision. No global body holds a veto.
- 17National adoption recordsRecord · Nexus StandardsComposed mission profiles and national adoption records go to the Foundry at readiness preparation (F08).
Nexus Standards · Nexus Standards (institution) · National Standards CouncilAn outline of the designed programme cycle, not a record of operation: no cycle has run and every programme is at service level R0. Every Nexus Standard is at the PROPOSED stage and nexustandards.com governs the text and status of each one. A UNI identifies and never certifies; a validator report is evidence for review, not a conformance claim.
The operations, as a table
| Step | Phase | Operation | Who | Decision rule | Record | Implements |
|---|---|---|---|---|---|---|
| 01 | Request | Request (start). The service covers: Reference charts and images, Residency defaults and federation peering and Air-gap packaging with vendored schemas and digests. | a client, a person or a machine | the context is explicit in the request or on the record, never inferred | a request naming its context and inputs | NS16-R20 |
| 02 | Request | Identify inputs (step). Every input is resolved before it is used; an unresolved input is a typed refusal. | the service | inputs are cited by UNI and version | inputs resolved to their UNIs and versions | NS1-R5, NS2-R2, NS0-P12 |
| 03 | Validation | Validate OCI Image (gate). Open standards of this area: OCI Image and Distribution Specifications, Sigstore (Cosign, Fulcio, Rekor), SPDX specification and Digital Public Goods Standard. | the service’s validator | validated against the open standard’s own schema or validator where one exists | a validation run against OCI Image and Distribution Specifications and Sigstore (Cosign, Fulcio, Rekor) | NS14-R2 |
| 04 | Processing | Process (model). Processing is reproducible from the inputs, the method version and the configuration. | the service | the method and version are recorded with the result | Residency defaults and federation peering | NS12-R1 |
| 05 | Processing | Write records (record). Results are written append-only; a correction adds a version. | the service | every result carries what it was derived from | result records with provenance and a record UNI | NS0-P7, NS1-R3 |
| 06 | Publication | Publish and resolve (step). Results are discoverable and citable by UNI. | the service | writes return the allocated UNI; citations resolve | results reachable through the resolver, with the X-Nexus-UNI header | NS1-R5, NS2-R5 |
| 07 | Monitoring | Monitor (exercise). Data sources the service reads: endoflife.date API, Artifact Hub API and OSV.dev vulnerability API. Data sources are listed for reference; live data is displayed once licence review is complete. | the monitoring service | monitoring records are observations with record UNIs | observations of availability, drift and SDG 17.6.1 | NS11-R4 |
| 08 | Monitoring | Correction (end). Products that used a corrected record are listed and recomputed. | the data steward | a correction never overwrites; dependent results are replayed | a correction record that reaches every dependent result | NS1-R3, NS2-R4 |
Table.Operations in walking order; each row names the phase, the operation, its actor, its decision rule, the record it leaves and the rule identifiers it implements. The table shows the process as specified; it does not report the status of any standard, proposal or record. Sources: OCI Image and Distribution Specifications · Sigstore (Cosign, Fulcio, Rekor) · NS-9: Contextual UNIs · NS-12: Software, model and AI/ML artefacts.
Routing, monitoring and verification tools
Deployment
Reference deployments and a sandbox with worked examples.
In progressMonitoring console
Version and source status for each standard, as published by the issuing bodies.
Available · from the registryVerification console
Test suites, conformance statements and attestations for each standard, as recorded in the registry.
Each console computes from the registry and states its reasoning; decisions remain with the competent bodies.
How a shock travels through this system
A system model of this area built from the registry: 4 systems, 4 sectors, 4 controls, 3 feeds, 2 indicators. Select the components to include, choose an initiating hazard and run the scenario. Stress propagates through the hazard relations of the Nexus Hazard Standard (NHS-1), the exposure of each system, the recorded couplings and the sectors that carry the loss; adopted standards dampen transmission and live data sources support detection. All parameters are stated assumptions that the reader can adjust; results are illustrative scenario outputs for exercises and training, not forecasts or risk assessments.
Systems and couplings
- Sovereign stack
- Sovereign deployment and data residency Coupling
- Deployment services Coupling
- Sovereign deployment pathway Coupling
Controls
NS-9Contextual UNIs (deployments, instances, programme instances)NS-12Software, model and AI/ML artefacts (supply chain, model cards, dataset sheets)NS-11Verification and monitoring (evidence, attestations, zero-trust conformance observation)NRS-A6One-click deployment and adoption kits
Observation
- endoflife.date API (listed for reference)
- Artifact Hub API (listed for reference)
- OSV.dev vulnerability API (listed for reference)
- Fixed Internet broadband subscriptions per 100 inhabitants
- Hosted build platform with signed provenance
Standards that apply
The area profile lists 3 Nexus Standards. Each is a proposed standard under development.
- 01
NS-9 · Contextual UNIs (deployments, instances, programme instances)
Status: proposed · 5 requirements stated. Read NS-9.
- 02
NS-12 · Software, model and AI/ML artefacts (supply chain, model cards, dataset sheets)
Status: proposed · 4 requirements stated. Read NS-12.
- 03
NS-11 · Verification and monitoring (evidence, attestations, zero-trust conformance observation)
Status: proposed · 6 requirements stated. Read NS-11.
Systemic couplings
3 couplings link this area to other areas and programmes, each with the mechanism of the link.
- Sovereign deployment and data residencyOpen Infrastructure and DevelopersImplements the residency, federation and air-gap requirements of the capability area in charts and defaults.
- Deployment servicesOpen Infrastructure and DevelopersImages in the reference deployment are built and signed by the deployment pipeline and verified at admission on the host.
- Sovereign deployment pathwayReadiness and AdoptionThe sovereign deployment pathway in the Readiness and Adoption programme uses this package as its reference deployment.
Open standards referenced
5 open standards, each with its relation as recorded in the register under NS-14. Hover over or focus a relation for its definition.
adopt4
OCI Image and Distribution SpecificationsOpen Container Initiativeproposed for the registerSigstore (Cosign, Fulcio, Rekor)OpenSSFlisted in the register · sigstoreSPDX specificationLinux Foundation (SPDX)listed in the register · spdxOpenTelemetry specificationOpenTelemetry (CNCF)proposed for the registerData sources
3 data sources named in the area profile, each with provider, licence, update frequency and delivery path.
Data sources are listed for reference; live data is displayed once licence review is complete.
- Live
- 0
- on completion of licence review
- Listed in the data register
- 0
- licence terms recorded
- Proposed for the register
- 3
- licence terms to be recorded
- Delivery
- 0 governed service · 0 plugin · 0 browser · 1 snapshot · 2 listed for reference
- proposed paths in order of preference: governed data service, plugin, direct browser read, build-time snapshot; sources whose terms do not permit reuse are listed for reference only
Artifact Hub APIfor reference
CNCF Artifact Hub · continuous
Apache-2.0 (service); packages keep their own licences
listed for referenceproposed for the data register.
endoflife.date APIfor reference
endoflife.date community · continuous
MIT
build-time snapshotproposed for the data register
OSV.dev vulnerability APIfor reference
OpenSSF / Google · continuous
Per-source licences aggregated by OSV.dev
listed for referenceproposed for the data register.
Indicators
The area profile names 2 indicators, each with its framework and code.
Indicator names and codes are given as published by their stewards.
Working group charter
A proposed charter for this area, open to institutions and experts.
Maintain the reference deployment, packaging and operations guidance.
Institutions and experts are invited to charter this working group under NS-13 by filing a public change record. National Working Groups (NWGs) contribute national inputs and field exercises through their National Nexus Consortium (NNC).
- Reference charts with signed images and SBOMs
- Air-gap bundle specification
- Operations runbook
- Digital Public Goods Alliance liaison sought
- CNCF liaison sought
- OSGeo liaison sought
Evidence, recognition and capital pathways
What each institution of the ecosystem draws from this area: The Global Centre for Risk and Innovation (GCRI Canada), as Secretariat, for evidence; The Global Risks Forum (GRF) for recognition; and The Global Risks Alliance (GRA) for capital.
GCRI Canada
GCRI Canada can run its analytical workflows within a national host when data cannot leave it.
The Global Risks Forum (GRF)
GRF recognises national deployments of the reference implementation as the host’s own statement, with the host’s receipt.
The Global Risks Alliance (GRA)
GRA readiness assessments for national programmes note whether the deployment is self-operated and how it is maintained.
Each institution determines under its own rules what it accepts as evidence; a pathway reading is neither an approval nor investment advice.
Open research questions
2 questions identified as priorities for the working group.
- Supporting hosts with very limited operations staff without hidden vendor dependency.
- Upgrades across many independent national hosts at different versions.
Restricted compatibility profiles
Standards whose text is not openly available are named and linked only. Any compatibility profile is kept on protected pages until an arrangement with the issuing body is in place.
The working group may identify restricted standards relevant to this area; they are listed here by name and link.
Intended users
The area profile identifies 4 user communities.
- National digital agencies
- Regional organisations
- University IT services
- Platform engineers
Hazards, threats and sectors concerned
Hazards and threats 0
This area draws on the hazards of the areas it is coupled with.
Sectors 0
This area serves all sectors through the areas it is coupled with.
Sources
3 references from peer-reviewed and official publications cited in the area profile, linked at the publishers’ own sites.
peer-reviewedReproducible Builds: Increasing the Integrity of Software Supply ChainsIEEE Software · 2022peer-reviewedData sovereignty: A reviewBig Data & Society · 2021- officialDigital Public Goods StandardDigital Public Goods Alliance · 2023
Recent research on this area
Recent peer-reviewed articles, preprints, datasets and reports on the subject of this area, retrieved at the time of reading from open scholarly metadata services (OpenAlex, Crossref, DataCite, Zenodo, arXiv, Europe PMC, OpenAIRE Graph) with search terms composed from the registry. Each work is listed with its authors, venue, year, type, open-access status and licence, and links to its DOI or landing page. Sources not yet enabled for live display on this site are listed for reference and are not queried.
Search termsdigital sovereignty; sovereign cloud; digital public infrastructure; Sigstore; SPDX specificationDerived from the title and scope of the area, the NHS-1 hazards it names and the open standards it lists.
- OpenAlexlisted for reference; not queried
- Crossreflisted for reference; not queried
- DataCitelisted for reference; not queried
- Zenodolisted for reference; not queried
arXivlisted for reference; not queried- Europe PMClisted for reference; not queried
- OpenAIRE Graphlisted for reference; not queried
No source is enabled for live display on this site yet: the sources are listed for reference and none is queried. Once the publisher of record enables a source after its terms are reviewed, recent works are listed here. Metadata and links only: title, authors, venue, year, type, open-access status and licence as each source records them; works are listed for orientation, not reviewed or endorsed.
Risk Academy courses and disciplines
1 course and 2 disciplines of Risk Academy (risksacademy.com) that teach the knowledge and methods of this area. Each course lists its level, stream and learning hours.
Courses
Disciplines
The correspondence between courses, disciplines and the Nexus Standards is maintained with Risk Academy and is subject to its academic review.
Programmes, tracks and courses for this area
GCRI Canada, The Global Risks Forum (GRF), The Global Risks Alliance (GRA) and Risk Academy work on the subject of this area in distinct roles (research and evidence; governance, policy and convening; capital, finance and markets; education and training). Each entry states why it corresponds and the step it offers; each institution sets its own terms of participation.
Research and evidence
GCRI Canada
Research programmes that produce the observations, models and assessments these records describe.
Data and ComputeEngineers public-interest data infrastructure and high-performance computing.Apply to this programme Digital Public InfrastructureStudies public cloud and concentration.Apply to this programme therisk.globalAll programmes of GCRI CanadaGovernance, policy and convening
The Global Risks Forum (GRF)
Tracks that convene public authorities, researchers and institutions on the governance of shared risks.
AI and Digital GovernanceExamines digital dependence.Join this track globalriskforum.comAll tracks of The Global Risks ForumCapital, finance and markets
The Global Risks Alliance (GRA)
Industry programmes in which financial institutions build a shared understanding of systemic risk.
Fintech NexusExamines open finance and application interfaces in financial services.Join this programme globalriskalliance.comAll programmes of The Global Risks AllianceEducation and training
Risk Academy
Courses and disciplines that teach the knowledge and methods practitioners need to apply these standards.
Technology and DataRAT-204 · Intermediate · 19 learning hoursManaging risk data, AI, digital infrastructure and technology risk responsiblyTake this course All courses and disciplinesListed in the education and training section of this pageKey terms
- UNI
- Unique Nexus Identifier: a persistent identifier that resolves an artefact to its record.
- proposed
- A draft in the open development process that the Global Standards Council has not yet adopted. Each area profile is a proposal to the Nexus Standards registry.
- adopt
- Relation in which the external standard is used as published and values are validated against it.
- crosswalk
- Relation in which clauses of these standards are mapped to parts of the external standard by clause number, without reproducing its text.
- change record
- A public record of a proposed change under NS-13, decided by the editors with written reasons.
- attestation
- An evaluator’s recorded result for one clause and one subject under NS-11.
- liaison sought
- A liaison the working group intends to request from the issuing body; a liaison is established only when the body confirms it in writing.
Related areas
Recent research and sources
Peer-reviewed articles, preprints, reports and datasets on the subject of this area, retrieved at the time of reading from open scholarly metadata services (OpenAlex and Crossref) and listed with authors, venue, year, type and access status, with a link to each work. Curated references and related standards are listed first; recent works matched by subject follow and are listed for orientation.
Curated references
- Data sovereignty: A review
Big Data & Society · 2021 · Peer-reviewed - Reproducible Builds: Increasing the Integrity of Software Supply Chains
IEEE Software · 2022 · Peer-reviewed - Digital Public Goods Standard
Digital Public Goods Alliance · 2023 · Official publication
Related standards and frameworks
- OCI Image and Distribution Specifications
Open Container Initiative - Sigstore (Cosign, Fulcio, Rekor)
OpenSSF - SPDX specification
Linux Foundation (SPDX) - Digital Public Goods Standard
Digital Public Goods Alliance - OpenTelemetry specification
OpenTelemetry (CNCF)
Search terms, derived from the title and scope of the area: digital sovereignty; sovereign cloud; digital public infrastructure. With JavaScript enabled, recent works matching these terms are listed from OpenAlex and Crossref.
Questions and answers.
What is the status of the Sovereign stack area?
How are data sources presented?
How can this brief be amended?
Contribute evidence from this page.
Reports is the Consortium’s quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.
- EmailGateway GW-STDSend it from this pageEvidence, a correction, a case, a method, a review, a translation or profile input. It arrives tagged with this page, so the editor who owns it receives it.
- ZenodoOpen depositDeposit it and submit to the communityPublish your own record on Zenodo with your ORCID iD, then submit it to the Reports community there. Curators review it; the DOI stays yours.
- ReportsNexus StandardsSee every way to contributeThe contribution types, how each is reviewed, what credit you receive, the licence and what is never accepted.
Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.
Contribute to Sovereign stack
Institutions and experts are invited to propose amendments, join the working group or propose data sources. National participation is organised through each country’s National Nexus Consortium (NNC) and its National Working Groups (NWGs); competent national authorities are engaged through official channels.
Status and use. The Nexus Standards are proposed standards developed through an open process under NS-13 and published for voluntary use; they do not constitute certification, accreditation or regulatory approval, and adoption remains a decision of the Global Standards Council and, in each country, of its National Standards Council. A UNI (Unique Nexus Identifier) identifies an artefact; it does not certify it. Names of standards bodies and their standards belong to their stewards and are used only to identify the documents; no text of an external standard is reproduced here. Nexus Standards is not affiliated with, endorsed by or certified by any standards body named here.
Licences: CC BY 4.0 for standards text, registries, schemas and data; Apache-2.0 for reference code. External standards are cited by name, number and link under their own licences. Third-party data, libraries and fonts keep their own licences: see Third-party notices.