Sovereignty is an architecture decision, not a procurement clause

Ask a vendor where your data lives and you will get a confident answer with a city attached. Ask where the control plane lives and the room goes quiet.

That second question is the one that matters. Data residency describes where bytes sit at rest. It says nothing about who can reach them, who holds the keys, whose update pipeline can change the behaviour of the system next Tuesday, or which jurisdiction can compel any of it. A platform can store every record inside the country and still be operated entirely from outside it.

The three planes

It helps to separate a system into three planes and ask the sovereignty question about each one independently.

The data plane is the records themselves: tracks, detections, imagery, logs. This is the plane everyone asks about, and it is the easiest to localise. Put the disks in the country and the clause is satisfied.

The control plane is everything that decides what the data plane does: orchestration, identity, key management, configuration, the deployment pipeline. If this plane is hosted as a service by someone else, they can change your system's behaviour without touching your data, and a legal order served on them reaches your operation without ever being served on you.

The knowledge plane is the models, the rules, the tuned thresholds and the operational judgement encoded over years of use. This is the plane nobody writes clauses about and the one that is hardest to get back. It leaves the country as telemetry, as training data, as support tickets.

A system is sovereign when all three planes are inside the boundary. Localising only the first is the common case, and it is the one that fails under pressure.

What this changes in practice

Designing for all three planes forces decisions early that are expensive to retrofit:

• Key custody has to be a first class part of the design, not a feature of the hosting contract. If you cannot revoke a vendor's access without their cooperation, you do not hold the keys.
• The update path has to be inspectable and interruptible by the operator. An air gap that you have to break monthly to stay patched is not an air gap.
• Models have to be trainable and retrainable inside the boundary. That means the training tooling ships too, not just the weights.
• The system has to degrade to a useful state when the outside link is gone, because in the scenarios that justify the purchase, it will be gone.

None of this is exotic. It is ordinary engineering discipline applied to a question that usually gets delegated to legal.

Why we build this way

We started Makedon because the operations that a country cannot afford to get wrong are being run on stacks where the answer to "who can turn this off" is a company in another jurisdiction. The clause in the contract does not change that. The architecture does.

That is the whole argument for building here, with the control plane and the knowledge plane inside the boundary along with the data. It costs more in the first year. It is the only version that holds in the year you actually need it.