A plant head has just watched a demo of a shopfloor assistant go well. It reads a fault code, cross-references the manual, and hands back a plausible cause inside a minute. He is halfway to signing when someone on his team asks the plain question: where did that answer actually come from. Not the logic — the location. Which server, in which building, in which country.
The vendor's engineer pauses, then says the account manager will follow up on that one. Nobody does. The proposal that arrives a week later describes a "secure cloud environment" and stops there, because there is nothing more specific to say. Nobody in the room can point to a map and put a finger down.
Why we build it this way
The demo was not dishonest. It just answered a question nobody had thought to ask yet, and the honest answer was that the fault code, the manual excerpt, and the plant's own service history had all left the building to get processed somewhere neither the vendor nor the buyer could name.
The instinct is to treat that as a compliance detail — a clause for legal to negotiate, fixed later with a better contract. That is the wrong order. If the point of any of this is a company that keeps its own knowledge and gets sharper from its own history, that knowledge has to live somewhere the company can see it, keep it, and take with it. A record sitting on infrastructure someone else controls is not a record the company owns, whatever the contract calls it. A vendor's terms can change, an account can be suspended, a company can be acquired — none of that touches the plain fact of where the file physically sits.
Sovereignty is not a feature we add once the interesting engineering is done. It is the condition that decides whether any of the rest is even possible.
So it decides the architecture from the first line, not the last one: models that run on hardware the customer owns, inside a boundary that can be drawn and named, working the same way with the uplink pulled out as with it plugged in. Get that wrong and everything meant to accumulate on top of it — every confirmed diagnosis, every corrected procedure, every rejected design and the reason for rejecting it — is memory kept somewhere else, by someone else, on their terms.
How it works, roughly
What we mean by sovereign is specific enough to check, not just to claim:
- The model runs on hardware inside the customer's own boundary — a server room, a rack in a data centre they hold the keys to, or a box on the shop floor itself
- Every place data would leave that boundary is drawn as a line on a diagram and given a name, so anyone can point at it and say who controls the far side
- The system keeps working with the internet connection pulled out, because a shed with a machine down does not always have signal, and an assistant that stops at the first outage was never really available
- Nothing about a diagnosis, a generated part, or the record that accumulates from either, depends on a call to a server the customer cannot walk up to
The test is one we put to ourselves as much as anyone else: can you draw every boundary your data crosses, and name who controls the far side of each one? An answer that takes a paragraph of hedging is a marketing position, not an architecture.
A year on, the plant that asked the awkward question owns the answer to it without asking again. The diagnoses, the corrected procedures, the record that has grown since — all of it sits on hardware inside a boundary the plant can point to, not a data centre it has to trust a contract about. A person still reads what the system says and decides what to do about it. The building it happens in is theirs.
Read the vision →