Open source code is necessary for sovereignty, but it is not sufficient. An organisation can run entirely open software and still be captive to the one vendor that knows how to operate it. Sovereign computing closes that gap by treating support itself as something you must be able to buy from more than one supplier.

The principle

A sovereign cloud must deliver support from Level 0 through Level 5. The defining property of an open sovereign cloud is that each level can be sourced from a different vendor. Any organisation offering support at a given level must expose open, documented interfaces to the levels on either side of it - downstream, towards the end user, and upstream, towards the maintainer.

Without those interfaces, the cloud is locked to a single support vendor, whatever the licence on its code.

The six levels

Level 0 — Self-service (free)

Documentation, FAQs, a public community forum, and Knowledge Briefs covering known defects and workarounds - published under a redistributable licence and offered through a machine-readable feed.

Level 1 — First contact

Human or AI-assisted help for end users, plus triage: deciding whether an issue belongs to the application, the cloud, the network, or the device, and raising a tracked ticket to the right Level 2 desk.

Level 2 — Helpdesk and application support

Staff experienced in the specific technology. They reproduce issues, apply known workarounds, resolve configuration problems, escalate genuine defects to Level 3, and contribute new workarounds back to Level 0.

Level 3 — Engineering

Root-cause analysis of suspected bugs and of issues with no existing Knowledge Brief. Produces documentation fixes, enhancement requests, defect filings to Level 4, or operational change requests - and a Knowledge Brief for each.

Level 4 — Vendor, upstream, and maintainer

The party that actually changes the code, the schema, or the hardware - upstream open source projects, commercial distribution maintainers, and hardware vendors.

Level 5 — Strategic and advisory

Long-horizon engagement: architecture, roadmap influence, regulatory alignment, multi-vendor coordination, and sovereignty assurance. Partial to the customer, not to any one vendor.

How escalation works

Consider a CRM service: a web application, running on platform infrastructure, on underlying infrastructure, reached by a client over a network. Two triage decisions structure the escalation across that stack:

• Level 1 decides whether the issue lies with the client, the network, or the application, and routes to the matching Level 2 desk.
• Level 3 decides whether the root cause is in the application, the platform, or the infrastructure, and routes to the matching Level 4 maintainer.

In an open sovereign cloud, each of those desks may be a different organisation. The handovers between them are therefore not internal workflow steps but contractual handovers, each crossing a documented, open interface.

The interfaces every level must expose

• a documented ticket or case-exchange API for handover between levels
• read access to Level 0 knowledge for every higher level
• a contribution path back into Level 0 knowledge from every higher level
• a bug or change-request API into the next level up

These interfaces are what let a customer mix providers - community Level 0, one vendor for Levels 1 to 3, the upstream project at Level 4 - and change any of them without losing continuity. That ability to switch is the practical test of sovereignty, set out in conformance and the Sovereignty Test.