Sovereign by design, not by slogan
Why an independent lab builds its whole stack on infrastructure it controls, and what sovereignty actually costs in engineering terms.
Every vendor sells sovereignty now. The word has drifted so far from its meaning that it now covers anything hosted in a jurisdiction with a flag you like. We use it in a stricter sense: you are sovereign over a system when you can operate, audit, rebuild and shut it down without asking anyone’s permission.
That definition has consequences. It rules out convenience before it rules out providers.
What it means in practice
In practice, sovereign infrastructure means four non-negotiable commitments: data stays where you put it with no third-party processor in the path; the audit trail is local and physical; every system is reproducible from a Git repository on hardware you can touch; and every component has a documented exit path before adoption.
For us, sovereign infrastructure means four commitments:
- Data stays where you put it. No third-party processor in the request path unless you chose it, and you can name it.
- The audit trail is local. Logs, prompts, documents: if a regulator or a customer asks where this data physically lives, the answer is a rack, not a region.
- Rebuild is a command, not a project. Everything we operate is described in code and reproducible from a Git repository on hardware we can touch.
- Exit is designed in. If a component disappears tomorrow, the migration path is documented before the component is adopted.
None of this is exotic. Carrier-grade network operators have worked this way for decades. What changed is that the tooling finally fits small teams: Talos Linux for declarative Kubernetes, Ansible for the metal, GitOps for the lifecycle.
What it costs
Sovereignty trades operational toil for control: you patch your own hypervisors, own the 3 a.m. disk-replacement pager, and maintain TLS rotation and capacity planning that a managed platform would absorb. The trade is worth it for the workloads that matter: scheduling data, security telemetry, customer identity. Not for everything.
Honesty requires the price tag. Sovereignty trades operational toil for control. You will patch your own hypervisors. You will own the 3 a.m. pager for a disk that decided to retire early. You will maintain TLS rotation, backup restores and capacity planning that a managed platform would absorb invisibly.
Our position is that this trade is worth it for the workloads that matter: scheduling data, security telemetry, anything that touches a customer’s identity. For the rest, pragmatism is a feature, not a compromise. The skill is drawing the line deliberately instead of inheriting it from a marketing deck.
Why this matters for AI
Large language models make sovereignty urgent: teams paste contracts, credentials, and customer data into external chat windows with only a data processing agreement as protection. The response is local inference for sensitive documents, a sanitization gateway in front of any external API, and reproducible evaluation runs versioned like any other artifact.
Large language models moved the goalposts. Teams now paste contracts, credentials and customer data into chat windows hosted who knows where, and the compliance answer is a data processing agreement nobody reads.
The same four commitments apply, almost unchanged:
- Local inference for sensitive documents, with model weights you can pin and audit.
- A sanitization gateway in front of any external API, redacting identifiers before dispatch.
- Evaluation runs you can reproduce, with prompts and outputs versioned like any other artifact.
This is the reasoning behind the products we are building at Cardinal Codes, and it is the thread you will find in every article on this blog: infrastructure decisions as sovereignty decisions.
Welcome to the field notes.