What a sealed enclosure means

The word sealed does a lot of work in descriptions of secure equipment, and it is worth being exact about what it means for a Czar node. It does not mean a padlock on a box. It means that the node was closed at a known state, that the state was recorded, and that the node can later show it is still in that state.

Two things on a Czar are sealed: the enclosure and the software image. This article takes each in turn and then explains what the pair gives a site that neither would give alone.

Sealed is a property, not a padlock

A seal on physical equipment is a statement about a moment. At the point of sealing, the node was in a particular configuration, and the seal marks that configuration as the one the site should expect. The value of the seal is not that it is hard to break but that breaking it is visible and that the sealed state is on a record somewhere.

For a Czar node, that record is the provenance record. Integration, sealing, and software load are recorded for every node. When the node arrives at the site and goes into the building's rack, the site is not asked to take anyone's word about what is inside. It is asked to compare the node against the record, and the node is built to make that comparison possible.

The image is sealed too

A sealed enclosure around software that can change would leave the more important half open. So the software image on a Czar is sealed, signed, and read-only. Sealed, in that it is a fixed load rather than an assembled one. Signed, so that its origin can be verified. Read-only, so that what is running does not drift from what was loaded.

The combination means the node's software has the same character as its hardware: it was fixed at a known state and it stays there until a deliberate, verifiable change. That change is a signed update bundle, which on an air-gapped site arrives on media and on a connected site is still downloaded and applied by the customer. Between updates, nothing on the node is different from what the record says. Signed updates that arrive by media covers the update path.

What the two seals give the site together

The point of sealing both is that it gives attestation something to attest. Each Czar node attests what it is running before it joins a Grid or accepts a task. That statement is only useful if there is a known-good state to compare it against, and the seals are what establish that state.

Picture a node arriving to replace one in the rack. The site has the provenance record for the new node: when it was integrated, when it was sealed, what software was loaded. The node powers up, attests what it is running, and the Grid admits it only if the attestation matches. Without the enclosure seal, the hardware could have been altered after the record was written. Without the image seal, the software could have been altered. With both, the record and the node describe the same thing.

Watchman continues the verification after joining, so the sealed state is not only checked at the door but kept under observation inside the building. The site's confidence in its rack rests on a check it can repeat rather than on a shipment it once accepted.

What sealing does not mean

Sealing is sometimes heard as abandonment, as if a sealed node were a box the site must live with and cannot touch. The arrangement is the opposite. Sustainment is part of the subscription for the configured Grid, and the site's job with respect to the node is to keep it in the rack, keep it on the facility's network, apply the signed updates it chooses to apply, and read the record.

Sealing also does not mean the site cannot see what the node does. The record of every decision, every task, every adaptation, and every attestation is on the operator's hardware, readable by the operator. What is sealed is the state of the machine, not the visibility of its behavior. A sealed node is more legible than an open one, because its state is known.

Why a building should care

A facility that runs robots on a pool is trusting that pool with perception and decisions for every machine on the floor. The question of what is in the rack is therefore not academic. A node that was altered somewhere between integration and installation would be serving the floor with software the site never agreed to.

Sealing, with the record behind it and attestation in front of it, is how a site answers that question from evidence. The node was closed at a known state. The state is on the record. The node proves it still holds that state before it serves a single robot. See Attestation before a node joins a Grid for the admission step and Czar for the appliance itself.