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:

1. Data stays where you put it. No third-party processor in the request path unless you chose it, and you can name it.
2. 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.
3. 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.
4. 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.

This post collects what we verified in production while engineering redundant peering for an operator environment, anonymized as always.

The baseline

The reference topology is two datacenters announcing the same /32 RIPE prefix through two transit providers each, connected by a private interconnect for state sync. The entire traffic steering policy reduces to four BGP community values: prepend x1, x2, x3, and a guarded blackhole, applied consistently at both sites.

The topology is deliberately boring: two datacenters, one /32 RIPE block announced from both, private interconnect for sync. Both sites receive full tables from two transits each. The interesting part is not the diagram, it is the policy attached to it.

Communities that earned their keep

Three BGP community conventions carried all the traffic steering weight: a canonical prepend ladder (x1, x2, x3) owned by a single ASN, inbound community rewriting at the edge into that canonical space, and a rate-limited blackhole community guarded like a firewall rule. The key insight is owning the vocabulary end-to-end.

Three conventions carried all the weight:

# Legible, stable, documented in the peering DB
65000:100   prepend x1 toward the tagged neighbor
65000:200   prepend x2
65000:300   prepend x3
65000:666   blackhole (URF-filtered, max-prefix protected)

Two details matter more than the scheme itself:

1. One ASN owns the vocabulary. Mixing your numbering with each transit’s own community table is how 3 a.m. pages are born. We rewrite inbound communities at the edge into our canonical space, and only the canonical space appears in route-maps.
2. The blackhole community is guarded. It is advertised only to upstreams that filter it correctly, and it is rate-limited on our side. A community that drops traffic is powerful enough to deserve the same review as a firewall rule.

The checklists

Two operational artifacts emerged from production incidents: a per-service drain procedure that shifts traffic with BGP communities before touching sessions, with expected packet counters at each step, and a “prove it” cron of synthetic probes from outside both sites that alert when the winning path diverges from the intended one.

After the inevitable night page (a maintenance where one site’s announcements were withdrawn a whole minute before the other site’s were accepted, leaving a window of nothing), two artifacts emerged:

• A drain procedure: per-service, per-direction steps to shift traffic with communities before touching sessions, with expected packet counters at each step.
• A “prove it” cron: synthetic probes from outside both sites that alert when the winning path is not the intended one. Steering without observation is just latency with confidence.

What we would do differently

Start active-active from day one with community-based preference instead of primary/backup. Backup configurations ossify quickly: the day you need them, they describe a network that no longer exists. And treat your community policy as executable documentation: writing it down is part of shipping it.

Announce from both sites from day one with prepends, instead of starting primary/backup and evolving later. Backup configurations ossify: the day you need them, they describe a network that no longer exists. Active-active with community-based preference degrades more gracefully than active-anything.

If you take one thing from this: your community policy is not configuration, it is documentation that executes. Treat writing it down as part of shipping it.