I would not let the words "sovereign-ready" into my own documentation

I struck the phrase "sovereign-ready" out of a deployment document in July and then spent two days finding out what I was supposed to write instead.

The strike itself was easy. I had written the phrase the way everybody writes it, in a sentence about supporting regulated and government deployments, and when I read it back I could not construct a test that would fail. There is no experiment whose outcome makes "sovereign-ready" false. It is not a claim. It is a posture, and I had put it in a document that was supposed to be a specification.

What replaced it is the subject of this edition: four deployment topologies, each a row in a table, each with a stated trust posture, and each of which had to answer a question the phrase let me avoid. Where does the certificate authority's key material live? What leaves the boundary? Who can compel disclosure of what?

Three of the four rows got harder to write. One of them got much harder. That is how I knew the table was better than the phrase.

This matters well beyond one repository, because the open-source AI stack is now genuinely capable of being deployed under conditions that would have been impossible eighteen months ago — open-weight models at frontier-adjacent quality, mature identity and policy infrastructure, working attestation, signed artifacts — and the question has moved from can this run without a hyperscaler to what exactly am I buying when someone says it can.

The phrase, and why it survives

"Sovereign-ready" survives because it is useful to everyone in the room and costly to nobody.

The vendor means: we can probably deploy this somewhere you approve of. The buyer hears: this satisfies my regulator. The procurement document records: sovereignty requirement — met. Nobody has said anything false, because nobody has said anything.

The same is true of most of the vocabulary in this area. "Data residency" tells you where bytes rest and nothing about where decisions are made. "On-premises" tells you where a container runs and nothing about what it calls out to. "Air-gapped" is used, routinely, for systems with a management plane that phones home. I have seen all three in procurement documents where the underlying deployment would have failed the buyer's own stated requirement, and in none of those cases had anybody lied.

The failure is structural. These phrases describe a disposition rather than a configuration, and dispositions cannot be tested.

What replaced it

Four topologies. I will give them plainly, then say what each one cost to write.

Topology A — local development. A developer machine. Everything runs, identity is mocked, certificates are self-signed. Trust posture: none, and it says so. No production data, ever. This row exists to be honest that the most common way anyone will first run the system is a way that guarantees nothing.

That was the easy row, and it is worth pausing on why it is in the table at all. Most vendors do not document their development posture, because documenting it means admitting that the demonstration you were shown proves nothing about the deployed product. Putting it in the same table as the sovereign row makes the difference between them explicit rather than implied.

Topology B — cloud-managed. The control plane is hosted. Mutual TLS, workload identity per tenant, per-tenant isolation. Trust posture: the operator of the control plane is in your trust boundary, and this is the row where that is stated as a fact rather than buried in an appendix.

Topology C — hybrid enterprise. The customer's own network holds the workloads; a synchronisation path carries audit material out. Key material is held in a customer-owned key management service. Trust posture: the customer holds the keys, and the vendor holds a stream of evidence.

Row C is where the writing got harder, because it forced a question I had been avoiding: what exactly is in the stream? An audit stream that carries receipts carries, by construction, a description of what agents did. Depending on what those agents touch, that is potentially regulated material crossing a boundary. The row cannot be written honestly without specifying what is in the stream and what is redacted, and once you specify it you have to build the redaction.

Topology D — air-gapped sovereign. An appliance. No external network. The certificate authority is backed by a hardware security module or a trusted platform module. Trust posture: the operator is the only party in the trust boundary.

Row D is where it got much harder, and that difficulty is the most useful thing in this piece.

Why the air-gapped row is the one that tells the truth

Writing "no external network" into a normative document obliges you to enumerate everything that would otherwise have crossed it. When I did that, the list was longer than I expected, and every item was a small, reasonable dependency that nobody would think of as a network call.

Update distribution. Certificate revocation checking. Time synchronisation. Telemetry, including the kind that is off by default but not absent. Any transparency-log anchoring for signatures. Any external attestation verification service. Threat-intelligence or policy-bundle refresh. License validation.

Every one of those has a defensible reason to exist, and every one of them is a hole in an air gap. And here is the part that generalises past my repository: most of them fail open. If a revocation check cannot reach its endpoint, the overwhelmingly common default is to proceed. Which means that a system deployed into a truly disconnected environment does not merely lose a feature — it silently loses a security property, and the loss is invisible because nothing errors.

Time synchronisation is the cleanest example. A signed receipt carries a timestamp and a validity window. In a disconnected deployment with drifting clocks, you eventually have two nodes that disagree about whether a credential is currently valid. There is no error message for that. There is a node that permits an action another node would have refused, and no operator will ever see the divergence.

So the air-gapped row forced three specific pieces of design work that the phrase "sovereign-ready" would have deferred indefinitely: an offline verification path that does not require reaching a transparency log; a revocation mechanism that does not depend on reaching an authority; and an explicit statement of the time-source assumption, with the failure behaviour written down.

None of that is exotic. All of it is the sort of thing a team does eventually, under pressure, badly, during a deployment. The difference is entirely in whether a document forced the question before or after a customer was waiting.

The one test that survives translation

Underneath the four rows there is a single question, and it is the only sovereignty test I have found that means the same thing in every jurisdiction.

Can a third party check your evidence with no privileged access and no shared secret?

That is it. If verifying what your agents did requires the vendor's cooperation — their service, their key, their console — then what you have is a logging system with good marketing, and its sovereignty properties are whatever the vendor's continued goodwill and continued existence provide.

If verification is reproducible from artefacts you already hold, using an implementation anyone can build from a specification, then the vendor's jurisdiction, corporate structure and future are all irrelevant to your ability to answer the question a supervisor asks.

I like this test because it is indifferent to geography. It gives the same answer for a bank in Mumbai, a ministry in Riyadh, a hospital system in Ontario and a defence supplier in Virginia. It does not require anyone to agree about which countries are trustworthy. It asks only whether you can check your own records without asking permission.

And it is falsifiable, which was the whole complaint about the phrase it replaces. Hand someone a receipt, take away their credentials, ask them to verify it. Either they can or they cannot.

What this has to do with open source, specifically

There is a version of the sovereignty conversation that is really a procurement conversation about which cloud. That version is not very interesting, and it will be resolved by contracts rather than by engineering.

The version that is interesting is this: verification independence requires that somebody other than the vendor can build the verifier. That is not a licensing preference. It is a structural requirement, and it can only be satisfied by a published specification plus at least one implementation nobody has to ask for.

Which is why the design I have been working on consumes rather than rebuilds. Workload identity from a graduated project rather than a homegrown scheme. Policy evaluation from established engines. Artifact signing and transparency from tooling that already has adoption and scrutiny. Attestation from the standards-track work and its reference implementations. Red-teaming from the open scanners that already have probe corpora nobody would rebuild.

The reason is not economy of effort, although it is that too. It is that every one of those layers is a place where a buyer needs to be able to verify without me. A component I invented and only I implement is a component whose correctness rests on my word — and my word is exactly what a sovereignty requirement exists to remove from the equation.

There is a discipline that follows and it is uncomfortable: the system must never present itself as a peer to the mature things it consumes. It is the layer that binds their outputs into one non-bypassable decision. Saying that plainly is what makes the genuinely novel parts credible, because a reader who sees an accurate account of what was borrowed has some reason to believe the account of what was not.

The regional picture, and why the topology is the portable unit

Three things happened in different places within a few months of each other, and they rhyme in a way that matters for anyone building.

In the Gulf, the United Arab Emirates announced in April 2026 an intention to move half of federal government sectors, services and operations onto agentic AI within two years. Saudi Arabia designated 2026 a year of artificial intelligence and, in July, its data and AI authority launched a national AI risk-management framework giving public and private entities a unified methodology for identifying, assessing, treating and monitoring AI risk. In the Dubai International Financial Centre, a regulation addresses autonomous and semi-autonomous systems directly, requiring impact assessment and risk-based audit for automated decision-making.

In India, the supervisory architecture is arriving through a different door — data protection obligations with hard deadlines attached, and draft model-risk material for the financial sector that has not been finalised while adoption accelerates regardless.

In North America, the framework that would have specified controls for model risk was revised in April 2026 with generative and agentic systems placed expressly out of scope, and separate guidance promised. The specification is pending, not absent in principle.

Different instruments, different legal traditions, different timelines. What they share is that each will, in the end, ask an operator to demonstrate something about a deployment — and demonstrations are made against configurations, not against postures.

That is the argument for the topology table as the portable unit. A country is not a deployment. A cloud region is not a trust posture. But "the certificate authority is backed by a hardware module inside the boundary, no external network is required for verification, and here is the failure behaviour when the time source drifts" means the same thing in Riyadh, Toronto, Mumbai and Virginia. It survives translation because it describes a machine rather than an intention.

What I got wrong

Two things, and the second is worse.

I originally wrote the topologies as a capability ladder — A through D, increasing in rigour, with D as the premium row. That framing is wrong and it took a reviewer to see it. The topologies are not a ladder; they are a set of different trust boundaries, and B is not a worse version of D. B is correct for an organisation whose threat model does not include the control-plane operator, and choosing D there buys operational pain for no security gain. Presenting them as a ladder pushes buyers toward the row that sounds most impressive rather than the row that matches their actual boundary, and that is a failure of a document that exists to make things checkable.

I described a topology I had never deployed. Row D is real in the sense that its requirements are specified and its dependencies are enumerated. It is not real in the sense that I have stood up an appliance in a disconnected environment and watched it run for a week. In the state document for this project that distinction is marked — observed, versus established from source, versus cannot be established from here — and row D is not in the first category.

I am naming it here because a sovereignty claim from someone who has not run the disconnected case is precisely the kind of claim this piece is complaining about. The enumeration of external dependencies is real work and I stand behind it. The claim that the whole thing runs happily disconnected for a month is not one I have earned.

What to check on Monday

One. Find "sovereign", "on-premises" or "air-gapped" in a contract or a security page you rely on. Ask what test would make it false. If there is no test, replace the sentence with a configuration, and notice how much longer it becomes.

Two. Take one deployment you believe is isolated. Enumerate every outbound connection it would make in a week — update checks, revocation, time, telemetry, license, log shipping. For each, ask what happens when it fails. Count how many fail open.

Three. Take one piece of evidence your system produces about an agent's behaviour. Hand it to a colleague. Remove their access to your systems. Ask them to verify it. Whatever they need that they do not have is the size of your dependency on the vendor.

Four. Ask where your certificate authority's private key is at this moment. If the answer is a file, a secret manager, or an environment variable, then your trust posture is whatever access to that store implies, in every topology you operate.

Five. If you run a disconnected or intermittently connected deployment, check whether two nodes can currently disagree about whether a credential is valid. That divergence produces no error, and it is the failure that nobody finds until it matters.

What I am not claiming

I am not claiming a four-row table is a sovereignty strategy. It is a way of forcing a claim to become a configuration, which is a precondition for a strategy rather than a substitute for one.

I am not claiming the enumeration of external dependencies is complete. It is complete against my current design and will grow the first time somebody deploys it somewhere I did not anticipate.

And I am not claiming that consuming mature open source is free of risk. It moves the risk rather than removing it — supply chain, maintainer capacity, version drift — and the honest version of that trade is that I would rather depend on a component with many eyes and a real security process than on one I wrote and only I have read.

The invitation

I want one thing from this edition, and it is specific.

I am looking for an organisation running a genuinely disconnected or heavily restricted estate — government, defence, critical infrastructure, a regulated environment with a hard egress boundary — that would be willing to put topology D under real conditions and tell me what breaks. Not a pilot. A week of running, and an honest list of everything that silently degraded.

The enumeration of external dependencies above is my best current answer, produced by reasoning about the design. I would rather have it corrected by somebody's operational reality than defend it.

If that is your estate, the interesting part for you is that you already know three things on that list that I have not thought of.

Claims register

• Four deployment topologies are specified, each with a stated trust posture · architecture document, §4 · verified — in source
• Topology D specifies no external network and an HSM- or TPM-backed CA · architecture document, §4 · verified — in source
• The design consumes SPIFFE/SPIRE, policy engines, Sigstore, attestation standards and open scanners rather than reimplementing them · repository README and portfolio re-cut · verified — in source
• Every receipt declares the enforcement mode it was produced under · enforcement-mode contract · verified — in source
• The third-party verification test is the stated central test · repository README · verified — in source
• UAE announced a 50% federal agentic AI intention in April 2026 · public announcement · read — characterised as an announced intention
• Saudi Arabia launched a national AI risk-management framework in July 2026 · national AI authority publication · read
• A DIFC regulation addresses autonomous and semi-autonomous systems · DIFC regulation · read
• US model-risk guidance was revised in April 2026 with agentic AI expressly out of scope · OCC Bulletin 2026-13 / Fed SR 26-2 · read — verified previously against the issuing agency
• The list of external dependencies that break an air gap · my enumeration against this design · read — reasoned from the design, not measured in a deployed disconnected estate
• Topology D has been deployed and observed running disconnected · — · unknown — not done. Stated as unearned.

What would falsify the central argument: a deployment that satisfies a buyer's sovereignty requirement while failing the third-party verification test. If that is possible, the test is not the right test, and I would want to know.