Who holds the keys on a facility pool

When an operator asks who holds the keys to a system, the useful answer is rarely about cryptography. It is about which decisions control the system and which person makes each one. On a facility pool there are a handful of such decisions, and this article names them and says who holds them.

The short version: the site holds all of them. The longer version explains what that means on a Tuesday afternoon when a route needs adding, a task needs approving, or a node needs looking at.

Keys as decisions, not objects

A key, in the sense that matters here, is the authority to change what the pool does. Four changes cover nearly everything. A route is opened or closed. A task is approved to run, or its bounds are changed. A node is admitted to the Grid or refused. A support session is opened to a person outside the building.

Each of these is a point at which the system could do something new. Sovereignty is the condition in which every one of those points is held by the operator. If any of them is held elsewhere, by default, by contract, or by a persistent connection, then someone outside the building can change what happens inside it without the building's consent.

The route key

The route key is the simplest to describe. On a connected Czar, Local Bridge permits only the routes the site declared and denies the rest. The declaration is the key. Whoever at the site is authorized to write it holds the authority to decide what the pool may reach.

That person is usually in the site's network or automation function, working with the integrator. They name the robot vendors' fleet software, the warehouse system, the PLCs, and stop. A route that is not in the declaration does not exist, so there is nothing for an outside party to use. On an air-gapped Czar the declaration is empty and the key is, in effect, the door to the room.

The task key

Site tasks are authored in Agency Studio, versioned, and bounded by zones, speeds, distances, and stops. Before any version runs on the floor, a named role approves it. That approval is the task key, and the site decides who holds the role.

In practice the role is often the safety officer or the automation lead, sometimes both in sequence. The point is that the approver is a person the site chose and can name, and that the approval sits in the record alongside every run of the task. When someone asks later why the robots were doing something, the answer includes who said they could.

The approval is also where the limits of the pool's authority are visible. The pool serves perception, decisions, and language. Stops, speed limits, reflexes, and motion limits remain on the robot as the vendor delivered them. A task approval bounds what the pool asks the robot to do; it does not loosen what the robot refuses to do.

The admission key

A node attests what it is running before it joins a Grid or accepts a task. Attestation is a check the node must pass, and the site holds the authority over which nodes belong. A node that does not attest correctly does not join, and the Grid continues without it.

This key matters most on day one and on the day a node is replaced. It gives the site a way to know, from the record rather than from a shipping label, that the hardware in the rack is running the sealed and signed image it was supposed to. Attestation before a node joins a Grid covers the step in detail.

The session key, and who holds none

The last key is the one most often surrendered by default elsewhere. No Czar ever opens a connection to the Element 31 portal. A remote session exists only when the customer opens one. On a sovereign site the customer must also attest, before the window is approved, that data disks are detached, the network is isolated, the console is supervised, and the person requesting has the authority. The window carries a hard expiry.

The customer's attestation is the session key. Nobody at Element 31 can turn it. The conditions are strict because the moment is the only one in which a person outside the building has a view in, and the site is entitled to control exactly when that moment begins and ends.

Element 31 provides sustainment and attestation underneath the Grid and signs the updates the customer downloads. It does not hold a standing route into any customer's pool, does not approve any customer's tasks, and does not open sessions on its own initiative. The robot vendors run their fleets and keep safety on their machines, and reach the pool only through a route the site declared. Under Czar Chassis, the vendor ships the Grid under its own name, but the decisions above stay with the building that runs it.

That leaves the operator holding every key, which is the only arrangement that deserves the word sovereign. For how the operator proves this later, see The audit question a site can answer. For the task layer where approvals live, see Technology.