Conformance and the Sovereignty Test
How an open sovereign cloud proves what it claims
A category is only as good as its definition of what qualifies. Sovereign computing makes its claims testable: a cloud demonstrates conformance through a published, signed report, assessed item by item against a shared checklist.
How conformance works
The conformance checklist uses the keywords MUST, MUST NOT, SHOULD, and SHOULD NOT in the sense of RFC 2119: MUST items are required for conformance; SHOULD items are strongly recommended, and any deviation must be justified in the report.
A cloud's conformance report completes the checklist item by item - each marked pass, fail, or not applicable, with rationale - dated and signed by the operator, and published openly. A cloud that claims to be an open sovereign cloud without a current public conformance report does not meet the definition.
What the checklist covers
- Cross-cutting requirements
- Every inter-level handover is exposed via a documented, versioned API; those APIs accept any licensed adjacent-level provider without a separate partnership; the operator publishes a machine-readable registry of providers at each level; and nothing in the operator's terms prevents a customer sourcing a provider independently.
- Per-level requirements (Levels 0 to 5)
- Each support level has its own checks - from Level 0's public documentation, forum, and machine-readable Knowledge Brief feed, through the ticket and escalation APIs at Levels 1 to 3, to Level 4's public issue tracker, public source, signed reproducible builds, and CVE feed, and Level 5's public governance and migration guarantees.
- Component conformance
- Every component is listed in a Component Conformance Manifest with its Level 4 status, and marked either substitutable or load-bearing.
The Sovereignty Test
Behind the detail is one practical test. A cloud passes only if all of the following are true at the same time:
- For each of Level 1, Level 2, and Level 3, the customer could today source that level from at least two independently owned providers. At Level 4, at least two independent organisations offer commercial-grade maintenance of the component.
- A customer that switches its Level 2 provider next quarter keeps its historical tickets, its Knowledge Brief contributions, and the operational telemetry it generated.
- Every interface used in such a switch is one of the documented APIs published under the cross-cutting requirements.
- The conformance report is published openly, dated, and signed.
A cloud that fails any one of these is not an open sovereign cloud, however much else it satisfies. The principle is simple: a customer that cannot change its Level 2 provider next quarter is not on a sovereign cloud.
How conformance becomes a procurable rating is covered in the Mark. The support levels it tests are described in the support model.