Skip to content
ELEMENT 31

Attestation before a node joins a Grid

A Czar node states what it is running before it is admitted to a Grid or given a task. If the statement does not match the record, the node stays out and the floor keeps running.

· 4 min read

IN SHORT

Before a Czar node joins a Grid or accepts a task, it attests what it is running, and the Grid compares that against the sealed, signed image on the node's record. A matching node is admitted. A node that does not match stays out, and the robots continue on the remaining pool or fall back to their on-board models, stopping rather than guessing.

There is a moment, every time a node is added to a facility pool, when the building decides whether to trust it. On most equipment that moment passes silently: the thing is plugged in, it appears on the network, and it starts doing work. On a Czar Grid the moment is explicit. The node has to say what it is running, and the Grid has to agree, before anything is served.

That step is attestation. This article describes when it happens, what it checks, and what the floor experiences when it fails.

The moment of joining

A Czar Grid is several Czar nodes acting as one pool for a facility. Adding a node, whether on installation day or when a unit is replaced, means the pool is about to let new hardware serve perception and decisions to every robot in the building. Before that happens, the node attests.

Attestation is a statement by the node about its own software state. It reports what it is running, and the Grid compares the report against the node's record: the sealed, signed, read-only image that was loaded when the node was sealed. If the two agree, the node is admitted and begins to carry its share of the pool. If they do not, the node is refused, and the pool carries on without it.

The site does not have to interpret anything. The check is binary and it is recorded. Either the node in the rack is the node on the record or it is not.

What a node attests

The content of the attestation is deliberately narrow. The node is not asked to prove it is healthy, fast, or well-configured. It is asked to prove it is running the software it was sealed with. That is the property a site cannot verify by looking, and the one that matters most, because everything the node does for the floor follows from the software it runs.

The provenance record supplies the other half. Integration, sealing, and software load are recorded for every node, so the Grid has a known-good state to compare against. Attestation without a record would be a node vouching for itself. A record without attestation would be a document with nothing to check it against. Together they let the site answer, from evidence, whether the rack holds what it was supposed to. What a provenance record contains describes the record side.

Before a task, too

A node attests before it joins a Grid and again before it accepts a task. The second check matters because a pool is not installed once and forgotten. Nodes run for a long time. Updates arrive. People have physical access to the rack. A verification performed only on installation day would say less and less about the node as time passed.

Attesting before each task means the floor is served only by nodes whose state is confirmed at the time of the work. The site task a humanoid is about to run, the pick an arm is about to attempt, the route a mobile robot is about to take: each is served by a node that just restated what it is running and was found to match. Watchman carries integrity verification forward between those moments, so the attested state is under continuous observation rather than periodic inspection.

What a failed attestation looks like on the floor

The design question behind attestation is what should happen when it fails, and the answer determines whether the mechanism is safe to rely on. If a failed check took the floor down, operators would be tempted to disable it. If a failed check were ignored, it would be theater.

On a Czar Grid, a refused node simply does not serve. The other nodes in the pool continue to answer the robots. If the pool as a whole cannot answer a robot in time, the robot does what it does whenever the pool is slow or absent: it falls back to its on-board model for reflexes, and its stops, speed limits, and motion limits stay on the machine as the robot vendor delivered them. A pool that fails leaves a robot that stops, not one that guesses.

So the cost of a refused node is capacity, not safety. The floor has less pool until the node is sorted out, and the robots behave as they would in any shortfall. Nobody is pressed to admit a node that failed in order to keep the building running.

Why the check belongs at the Grid

Attestation could, in principle, be a procedure the site performs by hand: inspect the seal, read a label, sign a form. Putting it in the Grid instead means it happens every time, with the same rigor, whether or not anyone is paying attention, and the result lands in the same record as every task and every decision.

That record is what the site reaches for later, when an auditor or an investigator asks what was running on the night in question. The answer is not a recollection. It is the attestation the node made before it accepted the task. The audit question a site can answer follows that thread. For the appliance and the Grid, see Czar Grid and Technology.

Questions this raises

What exactly does a node attest?
What it is running: the sealed, signed, read-only image it was loaded with, as recorded in its provenance record. The Grid admits the node when the attestation matches the record and refuses it when it does not.
Why attest again before a task if the node already joined?
Because joining is a moment and serving is continuous. Attesting before accepting a task means the floor is served only by nodes whose state is verified at the time of the work, not only at the time of installation.
What do the robots do while a node is refused?
They are served by the rest of the pool. If the pool cannot answer a robot in time, the robot falls back to its on-board model, and its stops, speed limits, and motion limits remain on the machine as the vendor delivered them. A pool that fails leaves a robot that stops, not one that guesses.

KEEP READING