How do updates reach an air-gapped site?

They are carried in. An air-gapped Czar has no path out, so nothing can be pushed to it over a network and nothing can be pulled by it either. Instead, Element 31 publishes each update as a signed bundle. Someone the site trusts downloads it from the customer portal on a machine that is allowed to be connected, moves it onto media, and brings it onto the floor. The node checks the signature, applies the bundle, and attests what it is now running before it serves another robot. The whole path is walked by people, which is the point of being air-gapped.

The bundle and the signature

A Czar runs a sealed, signed, read-only software image. An update is a new signed image, and the node refuses anything that does not carry a valid signature. That check happens on the node, with nothing external consulted, so a bundle that was altered in transit or that came from the wrong source is simply not accepted.

Because the image is read-only, an update is a replacement rather than a patch applied in place. The node is either running the previous signed image or the new one. There is no in-between state where part of the software has changed and part has not, which is what lets the node say plainly what it is running.

Who moves it and how

The download is customer-initiated. Signed update downloads are one of the things the customer portal exists for, alongside support and billing, and the portal is reached from the customer's own connected systems rather than from the appliance. Customer appliances never connect to the portal, in either posture.

From there the site follows its own media-handling procedure. Many air-gapped sites already have one for the PLCs and the vision systems on the line; the Czar bundle goes through the same door. The person who carries it in and the person who loads it are both named in the site's own process, and the load itself is recorded on the node.

After the load

Before a node rejoins the Grid or accepts a task, it attests what it is running. After an update that means the Grid knows the node is on the new signed image and not something else. If the attestation does not match what the site expects, the node does not rejoin.

Watchman, the integrity verification in Substrate, continues to check the running image after the update, so the state the site confirmed at load time is the state it can confirm later. The record of the load and the attestation stays on the operator's hardware, where an auditor can read it.

Because a Czar Grid is several Czars sharing one pool, an air-gapped site does not have to take the whole pool down to update it. Nodes are updated one at a time. While one is out, the others keep serving and robots keep their latency budgets; a robot whose request would have landed on the updating node is served elsewhere or falls back to its on-board model as it would for any miss.

The same bundle serves a connected site too; the difference is only how it arrives. Does Czar need the internet covers the postures side by side, and the Czar page describes the sealed node itself.