Who holds the keys

Sovereignty claims are cheap. Custody questions are not. Ask three of them about any system that describes itself as sovereign — who can decrypt the data, who can sign something the fleet will run, and who can revoke a machine's ability to work — and the answers describe the real distribution of power. They frequently disagree with the contract, the architecture diagram, and the vendor's entirely sincere intentions.

The disagreement is not about honesty. A contract is a promise about behavior; custody is a fact about capability. The difference surfaces on the day the promise becomes inconvenient: an acquisition, a change of terms, a legal demand served somewhere else, a support engineer improvising at the end of a long outage. Promises are renegotiated under pressure. Capability is what remains.

That makes sovereignty testable rather than declarative, and key custody is the test.

Four different jobs

Keys tend to get discussed as a single category, which is where the design goes wrong. In a system like this they do at least four distinct jobs, with different natural holders and different consequences for loss.

• Data keys protect what the facility produces, at rest inside the boundary. Video, telemetry, layouts, the day's episodes. These never need to exist outside the site, and any design in which they do has already answered the sovereignty question in the negative.
• Identity keys establish that a node is the specific node it claims to be. Created at provisioning, bound to hardware, not extractable. They are what attestation evidence is signed with, and what makes a substituted or cloned unit detectable rather than merely unlikely.
• Signing keys authorize artifacts — the images, models, and policies a fleet is willing to execute. These are the keys that reach directly into how machines behave.
• Administrative keys authorize action on the system itself: provisioning a node, admitting a bundle to a site, revoking an identity, recovering from a loss. They govern the process by which the other three are managed.

Collapsing these into one hierarchy is tempting because it is tidy, and wrong because their failure modes are not comparable. Losing a data key destroys data. Losing an identity key compromises a machine. Losing a signing key hands someone else authority over how a fleet moves. Losing an administrative key compromises the mechanism that would have contained any of the others. A design that puts all four under one authority makes the worst of those outcomes the result of any single mistake.

The tension nobody escapes

Here is the part that resists a clean answer.

For the system to be sovereign, the operator must hold the keys that matter. Otherwise the boundary is a promise held together by someone else's key management, and every guarantee the architecture makes is contingent on a party the operator cannot inspect. Follow that principle to its conclusion, though, and two uncomfortable facts appear at once.

The first is that a vendor able to sign what a fleet will run holds real authority over how machines behave, regardless of who owns the building or where the data sits. Data sovereignty combined with vendor-controlled behavior is a partial sovereignty routinely described as a complete one. The material that never leaves the site is beside the point if the behavior that acts on it arrives from outside on someone else's signature.

The second is that an operator holding everything alone owns a custody problem that is easy to get catastrophically wrong. Key management is a specialty, its failure modes are quiet, and the consequences land in a place with machines that have to keep working. Handing an operator every key and calling the result sovereignty can be its own form of abdication.

Both are true at once. The design question is therefore not which party should win, but how to structure authority so that neither party's mistake or compromise is sufficient on its own.

Building is not admitting

The most useful separation available is between the authority to build an artifact and the authority to admit it to a site. A builder signs to assert that this is what was made and it has not changed since. A site signs to assert that this is accepted here, for these machines, for this work. Two different claims, two different holders, and the second one is what gates execution.

That structure gives an operator something concrete rather than contractual: the ability to refuse. A bundle that arrives correctly signed by whoever built it, unaccompanied by the site's own approval, does not run. The rule a node enforces is not trust this signature but require both, and the one that cannot be supplied from outside is held by the party that owns the physical consequences.

Stated as a requirement rather than a courtesy: no vendor key should be sufficient by itself to make a fleet run something. Anything that changes how machines behave — a model, a policy, a configuration that shifts a limit — needs the operator's own approval step, performed inside the boundary, with a key the operator holds and can decline to use. This is the difference between an operator who can audit a supplier's behavior and one who has to take it on faith, and it costs a signature.

Losing a key where there is nothing to call

Holding keys creates a failure mode that outsourcing hides: losing them. At an air-gapped site this is not an inconvenience to be resolved by a support ticket, because there is no one to call and nothing to call with. A site that cannot sign can no longer admit anything — no update, no reversal, no new machine — and it reaches that state quietly, usually discovering it at the moment it needs to act.

Recovery therefore has to be a designed procedure rather than an improvisation. Which keys can be reissued, and by whom. What quorum of people is required, so that no single departure or single coercion is decisive. What the machines will accept as evidence that a new key legitimately succeeds an old one. How much a site can continue to do while the process runs. All of it executable by people physically present, using material already inside the boundary.

Recovery is also itself a power. A procedure that can restore signing authority is a procedure that can grant it, so it inherits the same requirements as the authority it restores: split across roles rather than resident in one person, recorded whenever exercised, and deliberately awkward. The two failure modes pull against each other — recovery that is too hard becomes a site that cannot function, recovery that is too easy becomes a second way in — and that tension is exactly why it belongs in the architecture rather than in an operations manual written later.

Revocation is easy to describe

Revocation is the last of the three questions and the least settled. Saying that an identity is no longer trusted takes one sentence. Making that sentence true, promptly, in a fleet whose machines are routinely unreachable is a genuinely hard problem.

Conventional revocation works by making the answer to a lookup change, which assumes the party checking can reach the place where the answer lives. The machines here may be disconnected for long stretches by design: a forward site, a vessel, a facility that never connects to anything. A revocation that only holds while a machine is online is not a revocation. It is a preference that applies when it is least needed.

So revocation state has to be data that travels. It rides the same signed bundles as everything else, is evaluated by a node when it rejoins, and is enforced by the parties a revoked machine depends on: the facility plane that would admit it to coordination, and the peers that will not share a floor with a unit unable to show current standing. A revoked machine may never learn that it was revoked. What has to be true is that everything it needs in order to work refuses it.

The unresolved part is freshness. A machine returning after a long absence is operating on old trust, and so is the site that receives it. How long standing may be carried, what a machine is permitted to do while its standing is stale, and how a fleet distinguishes a unit that has been away from one that has been tampered with are questions with physical consequences and no clean answer. We would rather name that as open work than present an expiry rule as though it settled anything.

The test is architectural

Each of these questions has a comfortable answer that is quietly disqualifying. That the operator's keys are held in a managed service. That revocation is handled centrally. That recovery is a support process. Those answers are workable for software and wrong for a fleet that has to keep operating when nothing is reachable and has to demonstrate, afterward, who authorized what.

The test worth applying to E31 Network is the one worth applying to anything making this claim. Can the operator hold the keys that matter. Is the behavior of the system under those keys inspectable rather than promised. Does everything the vendor holds fall short of being sufficient on its own. Sovereignty that depends on a vendor's restraint is a policy. Sovereignty that follows from who holds what is an architecture, and only one of the two can be examined before it is needed.