Support definitions
Level definitions, conformance of service delivery, and the scoring rubric
The support model page states the principle and the six levels. This page is the detailed reference behind it: what each level means, what a provider must do to conform at that level, and how a service is scored. It is the working definition used when assessing a provider against the support model.
Principle
A Sovereign Cloud must deliver Level 0 through Level 5 support as specified below. A core property of an open Sovereign Cloud is that each level can be sourced from a different vendor. This means any organisation offering support at a given level must expose open, documented interfaces for interacting with support organisations at adjacent levels — both downstream (toward the end user) and upstream (toward the maintainer). Without these interfaces, the cloud is functionally locked to a single support vendor regardless of the licensing of its underlying code.
Support hierarchy (illustrative)
Consider a worked example: a CRM service, delivered as a web application, running on platform infrastructure, which in turn runs on infrastructure, reached by a client over a network. The system being supported is a layered stack:
The system being supported is a layered stack. A client (browser or device) reaches the CRM web application over a network; the application runs on platform infrastructure, which in turn runs on infrastructure:
- Client - browser or device
- Network
- CRM web application
- Platform infrastructure
- Infrastructure
A fault reported by the end user can originate at any of those layers, which is why triage decides which stack layer owns the problem before escalation chooses which vendor it goes to.
Two triage decisions structure the escalation across this stack:
- Level 1 decides whether the issue belongs to the client, the network, or the application — and routes to the corresponding Level 2 desk.
- Level 3 decides whether the root cause lies in the application, the platform, or the infrastructure — and routes to the corresponding Level 4 maintainer.
Escalation through that stack runs as follows.
- Level 0 - Self-service. Documentation, community forum, knowledge briefs. The end user starts here.
- Level 1 - First contact. Triage: is this the client, the network, or the application?
- Level 2 - Helpdesk, on the branch triage selected: client/device, network, or CRM application.
- Level 3 - Engineering, on the same branch. Where the branch is the application, engineering determines root cause: application, platform, or infrastructure?
- Level 4 - Vendor, upstream or core maintainer for whichever component root cause identified: the CRM application vendor, the platform maintainer, or the infrastructure vendor.
Each hand-off crosses an organisational boundary, which is the point: every one of those boxes can be a different company.
Note that application appears in both triage decisions: an application fault may be a usage or configuration matter (resolved at Level 2) or a genuine code defect (escalated through Level 3 to the application vendor at Level 4). The client and network paths each have their own Level 3 engineering function; only the application path carries the layer-triage that fans out to platform and infrastructure maintainers.
In an open Sovereign Cloud, each box in the first diagram may be operated by a different organisation. The arrows are therefore not internal workflow steps but contractual handovers, each of which must cross a documented, open interface.
The interfaces required at each level are:
- A documented ticket / case-exchange API for handover between levels.
- Read access to Level 0 knowledge for all higher levels.
- A contribution path back into Level 0 knowledge from all higher levels.
- A bug / change-request API into the next level up.
Level Definitions
Level 0 — Self-Service (free to use)
Documentation, self-help information, community information, Knowledge Briefs, defect and workaround descriptions.
An open Sovereign Cloud must publish, at no cost and without registration barriers:
- Reference documentation covering all user-facing and operator-facing functionality.
- How-To guides and FAQs for the common tasks an end user, developer or operator is expected to perform.
- A community forum where users may exchange information and seek peer assistance. The forum must be publicly readable and indexable by search engines, so that answers given once are discoverable by all.
- Knowledge Briefs of the form normally consumed by Level 1–3 support, including known defects, current workarounds, and the status of any related upstream fix.
- A machine-readable feed (RSS, Atom, or equivalent API) for new and updated Knowledge Briefs, so that downstream support organisations can mirror or ingest them.
TODO: CVE info should be available
All Level 0 content must be available under a licence that permits redistribution, so that a higher-level provider may bundle or extend it for its own customer base.
Level 1 — End User / First Contact (commercial contract)
Human-assisted or AI-assisted support for end users. Typically a shared function spanning the cloud, the end-user device, the network and the applications running on top.
Level 1 has two objectives:
- Help end users use the solution as documented — in principle, anything an attentive user could have resolved with Level 0 material.
- When the interaction cannot be resolved at Level 1, raise a trackable ticket against the correct Level 2 desk. This requires basic triage to determine whether the issue relates to the end application, the underlying cloud, the network, or the client device — each of which may have a different Level 2 provider.
An open Sovereign Cloud provider does not typically offer Level 1 directly, because the cloud itself is not the end product. Organisations offering Level 1 for solutions running on the cloud must be given:
- Free, programmatic access to all Level 0 material (the same feeds described above).
- An open ticket-creation API to the cloud's Level 2 desk, with documented schemas for incident classification, severity, affected component, and end-user identity (subject to applicable data-protection rules).
- A ticket-status API, so that the Level 1 agent can report progress back to the end user without telephoning a counterpart.
Level 2 — Helpdesk / Application Support (commercial contract)
Deeper support by staff experienced in the specific technology in question, with domain or device expertise applied where required.
Level 2 owns a ticket from the moment Level 1 hands it over until it is either resolved or escalated. The Level 2 organisation is expected to:
- Reproduce the issue against a known configuration of the cloud.
- Apply known workarounds from the Level 0 Knowledge Briefs.
- Resolve issues attributable to misconfiguration, capacity, or documented behaviour.
- Escalate to Level 3 when the issue cannot be explained by existing knowledge — i.e. when new knowledge must be constructed, or when a code change is suspected.
- Contribute back to Level 0 any new workaround or clarification that emerges in the course of the work, so the next caller does not pay to rediscover the same answer.
To remain sourceable from a vendor different from the Level 1 or Level 3 providers, a Level 2 organisation must expose:
- An inbound ticket API consumed by Level 1 providers.
- An outbound escalation API to whichever Level 3 organisation supports the affected component.
- A write API into the Level 0 knowledge base for publishing new Knowledge Briefs and workarounds, subject to editorial review.
Level 3 — Technical Support / Engineering (commercial contract)
Triage of suspected bugs and of issues for which no Knowledge Brief yet exists. Root-cause analysis. Production of operational change requests or upstream bug filings.
Level 3 is where new knowledge is created. A Level 3 engineer takes a ticket that Level 2 could not resolve and determines:
- Whether the system is behaving as designed and the documentation is at fault — output: a documentation update fed back to Level 0.
- Whether the system is behaving as designed but the design is wrong for the user's case — output: a system enhancement request to Level 4.
- Whether the system is malfunctioning — output: a defect filing to Level 4, with reproduction steps, logs and, where possible, a minimal test case.
- Whether the issue is operational — output: an operational change request to the cloud operator (which may or may not be the same organisation).
Open-interface requirements:
- A defect-filing API into the upstream / Level 4 issue tracker for every component the Level 3 provider supports.
- A change-request API into the cloud operator's change-management system.
- A write API into Level 0 for Knowledge Briefs that describe the new defect and any interim workaround, published immediately rather than after the upstream fix lands.
Level 4 — Vendor / Upstream / Core Maintainer (commercial contract)
The party that actually changes the code, the schema, or the hardware.
For an open Sovereign Cloud, Level 4 is typically a mix of:
- Upstream open-source projects (kernel, hypervisor, container runtime, orchestrator, database, identity, etc.).
- Commercial distribution maintainers who package, harden and sign those upstream projects for production use.
- Hardware vendors for firmware-level defects.
Level 4 responsibilities:
- Accept defect reports and enhancement requests from any qualified Level 3 organisation, regardless of commercial relationship.
- Triage, schedule, and release fixes against a published roadmap.
- Publish signed release artefacts and reproducible build information.
- Operate a coordinated vulnerability-disclosure process with a documented embargo policy.
Open-interface requirements — these are what distinguish a genuinely sovereign cloud from one that is merely built on open source:
- A public issue tracker accepting submissions from any Level 3 provider, not only from commercial partners.
- A public source repository with a contribution path open on the same terms.
- A published roadmap and release calendar.
- Signed, reproducible builds, so that a sovereign operator can verify what it is deploying.
- A CVE / advisory feed in a machine-readable format.
A component whose Level 4 does not meet these requirements cannot honestly be described as part of an open Sovereign Cloud, regardless of the licence on its source code.
Level 5 — Strategic / Advisory Escalation (commercial contract)
Long-horizon engagement covering architecture, roadmap influence, regulatory alignment, multi-vendor coordination and sovereignty assurance. Not concerned with individual incidents.
Level 5 is the layer at which a customer organisation — typically a government body, regulated industry or large enterprise — engages with the cloud ecosystem on questions that do not fit on a ticket:
- Architectural advisory — how to compose the available components for a given workload, redundancy or sovereignty requirement.
- Roadmap influence — representing the customer's needs in upstream governance and in commercial distribution planning.
- Regulatory and compliance advisory — mapping cloud capabilities and operational practice to the customer's regulatory obligations (data residency, sector-specific rules, audit requirements).
- Multi-vendor coordination — brokering responsibility between independently contracted Level 1–4 providers when an incident or initiative crosses their boundaries.
- Sovereignty assurance — independent assessment that the cloud, as deployed and supported, remains genuinely portable and independent of any single vendor.
A Level 5 advisor is by nature partial to its customer, not to any one vendor in the support chain. For the sovereign-cloud model to function, an open Sovereign Cloud must therefore:
- Conduct its governance in public, with documented decision processes that a Level 5 advisor and its customer can observe and participate in.
- Allow the customer (via its Level 5 advisor) to replace any of its Level 1–4 providers without losing access to historical tickets, knowledge contributions or operational data. This is the practical test of sovereignty: a customer that cannot change its Level 2 provider next quarter is not on a sovereign cloud.
Conformance of Service Delivery
This section is intended for self-assessment by a cloud operator, and for independent audit. The keywords MUST, MUST NOT, SHOULD and SHOULD NOT are used 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 published report.
A cloud's conformance report consists of this checklist completed item-by-item, with each item marked pass, fail or not applicable (with rationale), dated and signed by the cloud operator. The report must be published openly. A cloud claiming to be an open Sovereign Cloud without a current public conformance report does not meet the definition.
A. Cross-cutting requirements
| ID | Level | Requirement |
|---|---|---|
| CC-1 | MUST | Every inter-level handover described in this SLD is exposed via a documented, versioned API. Evidence: published machine-readable specifications (OpenAPI, AsyncAPI, or equivalent). |
| CC-2 | MUST | All inter-level APIs accept authenticated requests from any commercially licensed provider at the adjacent level, without requiring a separate commercial partnership with the implementing organisation. |
| CC-3 | MUST | The cloud operator publishes a registry of active providers at each level, with the components or domains each provider supports. The registry is machine-readable. |
| CC-4 | MUST | The cloud operator does not contractually prohibit a customer from sourcing a Level 1–4 provider independently of the operator. |
| CC-5 | SHOULD | Inter-level data formats follow a recognised industry schema where one exists; otherwise they are published as an open schema. |
| CC-6 | SHOULD | Every published API carries a deprecation policy with a minimum notice period (suggested: 12 months). |
B. Level 0 — Self-Service
| ID | Level | Requirement |
|---|---|---|
| L0-1 | MUST | Reference documentation for all user- and operator-facing functionality is published at a stable URL, without authentication. |
| L0-2 | MUST | FAQs and How-To guides cover the documented core workflows for end users, developers and operators. |
| L0-3 | MUST | A public community forum exists, is publicly readable, is search-indexable, and accepts questions from any registered user. |
| L0-4 | MUST | A Knowledge Brief catalogue is published, covering known defects, current workarounds, and the status of any related upstream fix. |
| L0-5 | MUST | A machine-readable feed of new and updated Knowledge Briefs is provided (RSS, Atom, or equivalent). |
| L0-6 | MUST | All Level 0 content is released under a licence permitting redistribution and modification by higher-level providers. |
| L0-7 | SHOULD | The Knowledge Brief catalogue reports the time-to-publication from Level 3 root-cause identification. |
C. Level 1 — End User / First Contact
These checks apply to the cloud, not to Level 1 organisations themselves: they verify that the cloud enables an open Level 1 market.
| ID | Level | Requirement |
|---|---|---|
| L1-1 | MUST | The cloud's Level 2 desk publishes an open ticket-creation API consumable by any Level 1 provider, with documented schemas for classification, severity, affected component and end-user identity (subject to data-protection law). |
| L1-2 | MUST | A ticket-status API is available to the originating Level 1 provider for every ticket it has created. |
| L1-3 | MUST | The Level 0 feeds (L0-5) are programmatically accessible to Level 1 providers at no cost. |
| L1-4 | SHOULD | The cloud publishes a triage guide enabling Level 1 to determine whether an issue belongs to the cloud, the application, the network or the device. |
D. Level 2 — Helpdesk / Application Support
| ID | Level | Requirement |
|---|---|---|
| L2-1 | MUST | The Level 2 organisation exposes a documented inbound ticket API satisfying L1-1. |
| L2-2 | MUST | The Level 2 organisation exposes a documented outbound escalation API to each Level 3 provider it relies on. |
| L2-3 | MUST | The Level 2 organisation has a published write path into the Level 0 Knowledge Brief catalogue, with an editorial SLA for publication. |
| L2-4 | MUST | Tickets owned by Level 2 carry persistent IDs that survive a change of Level 2 provider; the ticket history is the property of the customer, not the vendor. |
| L2-5 | SHOULD | Level 2 publishes its mean and 95th-percentile time-to-resolution, broken down by component class. |
E. Level 3 — Technical Support / Engineering
| ID | Level | Requirement |
|---|---|---|
| L3-1 | MUST | The Level 3 organisation has documented defect-filing access to the Level 4 maintainer of every component it supports. |
| L3-2 | MUST | The Level 3 organisation has a documented change-request channel into the cloud operator's change-management system. |
| L3-3 | MUST | The Level 3 organisation contributes a Knowledge Brief to Level 0 for each new defect or workaround it identifies, within a published timeframe. |
| L3-4 | MUST | Level 3 root-cause analyses are made available, in summary form, to the Level 2 and Level 1 providers that escalated the originating ticket. |
| L3-5 | SHOULD | Level 3 publishes anonymised statistics on defect classifications (documentation gap, design issue, code defect, operational) so that upstream maintainers and the cloud operator can prioritise. |
F. Level 4 — Vendor / Upstream / Core Maintainer
These checks apply per component. A component is not part of an open Sovereign Cloud unless its Level 4 passes.
| ID | Level | Requirement |
|---|---|---|
| L4-1 | MUST | The component has a public issue tracker that accepts submissions from any Level 3 provider. |
| L4-2 | MUST | The component's source is publicly available; patch contributions are accepted on terms that do not require commercial partnership. |
| L4-3 | MUST | The component has a published roadmap and release calendar. |
| L4-4 | MUST | Releases are cryptographically signed and the build is reproducible from public sources. |
| L4-5 | MUST | A coordinated vulnerability-disclosure process is published, including embargo terms. |
| L4-6 | MUST | A machine-readable CVE / advisory feed is provided. |
| L4-7 | SHOULD | Component governance (decision rights, maintainer succession) is publicly documented. |
G. Level 5 — Strategic / Advisory
| ID | Level | Requirement |
|---|---|---|
| L5-1 | MUST | The cloud's governance processes are conducted in public, with decision records accessible to customers and their Level 5 advisors. |
| L5-2 | MUST | The cloud publishes the data and metadata a customer would need to migrate at any level — ticket history, contributed Knowledge Briefs, and operational telemetry the customer has generated. |
| L5-3 | MUST | The cloud operator's terms of service permit a customer to change its Level 1, 2, 3 or 4 provider at any time, subject only to ordinary contractual notice. |
| L5-4 | SHOULD | An independent body (standards consortium, regulator, or audit firm) periodically certifies the cloud's conformance against this SLD. |
H. The Sovereignty Test
A cloud passes the sovereignty test only if all of the following are simultaneously true at the time of assessment:
| ID | Requirement |
|---|---|
| ST-1 | For each of Level 1, Level 2 and Level 3, the customer can list at least two independently owned providers from which it could source that level today. At Level 4, where the upstream is a single project, at least two independently owned organisations must offer commercial-grade maintenance and packaging. |
| ST-2 | A customer that switches its Level 2 provider next quarter does not lose access to historical tickets, Knowledge Brief contributions, or operational telemetry generated under the previous provider. |
| ST-3 | Every interface invoked in such a switch is one of the documented APIs published under CC-1. |
| ST-4 | The completed conformance report is published openly, dated, and signed by the cloud operator. |
A cloud that fails any item in the Sovereignty Test is not an open Sovereign Cloud, however many other items it satisfies.
Scoring Rubric
Purpose
This rubric translates the conformance checklist into a tier classification that procurement officers and customers can compare across competing clouds. The tier is a coarse classification intended for a comparison spreadsheet; within-tier ranking is by operational metrics and market plurality, not by raw MUST-item count.
Tiers
Tier 1 — Conformant
The cloud:
- Passes every MUST in section A (Cross-cutting) and sections B–G (Levels 0–5).
- Passes every item in section H (Sovereignty Test).
- Has a current published conformance report (no older than 12 months), signed by the cloud operator and verified by an independent auditor.
- May fail individual SHOULDs; each failure is named in the report with rationale.
Tier 2 — Conformant with Exceptions
The cloud:
- Passes every MUST in section A (Cross-cutting).
- Passes every item in section H (Sovereignty Test).
- Fails no more than 10% of the applicable MUSTs in sections B–G, and no more than one MUST in any single section. (A cloud that fails most of section F, for example, is fundamentally vendor-locked at the upstream layer and does not qualify regardless of percentage.)
- For each MUST failure:
- The failure is named in the conformance report.
- A published remediation plan names a target date.
- No exception persists across two consecutive annual reports without renewed justification.
- Has a current independently audited conformance report.
Tier 3 — Aspirant
The cloud:
- Passes every MUST in section A (Cross-cutting).
- Has a published roadmap to Tier 1 with dated milestones.
- Has a current self-assessed conformance report (independent audit not yet required).
- May fail items in section H but lists each one honestly.
This tier exists for clouds under construction or in early operation. A cloud SHOULD NOT remain in Tier 3 longer than 24 months from first commercial customer.
Tier 4 — Non-conformant
Any cloud not meeting Tier 3 — including any cloud that claims a higher tier without a current public conformance report.
Component conformance
A cloud is a composition of components. The operator MUST publish a Component Conformance Manifest listing every component, its Level 4 maintainer, and that component's status against L4-1 through L4-6.
The cloud's overall tier is bounded by the weakest-conformant component, with one exception: a component that fails Level 4 checks but is substitutable by the customer through the cloud's documented APIs does not reduce the cloud's tier. The Component Conformance Manifest must mark each non-conformant component as either substitutable or load-bearing.
A cloud that contains any load-bearing, non-conformant Level 4 component is Tier 4, regardless of other scores.
Evidence classes
Claims in the conformance report must be backed by one of:
| Class | Meaning | Acceptable for |
|---|---|---|
| P | Publicly verifiable — a linked, dated public artefact | Any item |
| A | Audit-verified — confirmed by the independent auditor's review of internal systems | MUSTs in sections B–G, items requiring access to non-public systems |
| D | Declared — self-declared by the operator only | SHOULDs only; does not count toward tier qualification |
Tier 1 and Tier 2 require Class A or P for every MUST. Tier 3 may use Class D for MUSTs in sections B–G, but not for items in section A or H.
Comparison sheet
The minimum comparable summary across competing clouds — fields a procurement officer should be able to fill in side-by-side:
| Field | Source |
|---|---|
| Cloud name | — |
| Cloud operator | — |
| Assessed tier | This rubric |
| Last audit date | Conformance report |
| Auditor identity | Conformance report |
| Independent providers at L1 / L2 / L3 / L4 | ST-1 evidence |
| Open MUST exceptions (count) | Sections B–G |
| Open SHOULD gaps (count) | Sections B–G |
| Load-bearing non-conformant components (count) | Component Conformance Manifest |
| Percentage of SHOULDs satisfied | Sections B–G |
| Conformance report URL | — |
Within-tier ranking
Two clouds in the same tier are differentiated, in order of priority:
- Number of independent providers per level (more = better — proves market plurality, not just latent openness).
- Percentage of SHOULDs satisfied.
- Operational metrics published under L2-5 (time-to-resolution) and L0-7 (time-to-publication).
- Audit recency (more recent = better).
- Number of load-bearing components (fewer = simpler substitutability).
What this rubric refuses to score
Some properties of a sovereign cloud cannot honestly be reduced to a procurement sheet and must be assessed in a parallel due-diligence process:
- Strategic alignment of the cloud's governance with the customer's legal and regulatory environment.
- Quality of Level 5 advisory available to the customer.
- Political and ownership exposure of the operator and of each component's Level 4 maintainer.
A cloud that scores Tier 1 on this rubric may still be inappropriate for a particular customer for these reasons. The rubric measures openness and replaceability; it does not measure fitness for a specific sovereignty mandate.