Day one: installing a Czar Grid
What actually happens when sealed Czar nodes arrive at a facility: rack placement, posture decisions, attestation, declared routes, and the first robot that asks the pool a question.
· 4 min read
IN SHORT
Installing a Czar Grid is mostly facility work, not appliance work. Sealed nodes go into the building's own rack, each node attests its signed image before joining the pool, the site declares which systems the pool may reach, and robots are pointed at the pool one fleet at a time. Element 31 engineers do this on the floor with the operator's automation team and the robot vendors.
The first day of a Czar Grid installation is mostly about the building, not the appliance. The nodes arrive sealed. The work is deciding where they sit in the rack, which part of the network they see, which robots they will serve, and which posture the site has chosen. Element 31 engineers do that work on the floor with the operator's automation team, the integrator, and the robot vendors who already have machines moving.
Nothing about the day requires the site to open an enclosure or load software by hand. The image is signed and read-only. The decisions are the site's; the sealing is Element 31's.
Before the crate is opened
The useful conversations happen before anyone touches a rack. The automation lead, the safety officer, and the integrator walk the floor with the installing engineers and settle a short list of questions. Which fleets will use the pool first. Which rack has the power and the network drop. Whether this site runs air-gapped or connected to systems it already secures.
That last question shapes everything after it. An air-gapped site will receive updates as signed bundles carried in by media, and the installing team plans for that from the start. A connected site lists the systems the pool is allowed to reach: the robot vendors' fleet software, the warehouse system, the controllers on the line. Nothing goes on that list by default. A connection is a decision someone makes and someone signs.
Racking and attestation
The nodes go into the building's own rack. A single Czar is a pool for a small floor; several joined together are a Czar Grid, one pool for the whole facility. The physical work is unremarkable, which is the point.
What happens next is not. Before a node joins the Grid it attests what it is running: the sealed, signed image and nothing else. The result is recorded. The site's first artifact from the pool is therefore a record of what each node is, written by the node itself, rather than a statement from a vendor. The provenance of each node, its integration, sealing, and software load, is already on record and travels with it. If the safety officer asks where the hardware came from, the answer is a document, not a reassurance.
Declaring the routes
With the nodes attested and joined, the team configures what the pool may talk to. Substrate's Local Bridge admits only declared routes and denies everything else by default. On a connected site, the integrator and the automation team name each system the pool needs: a fleet manager here, the warehouse system there, a controller interface on the assembly line. Each one is written down and approved.
On an air-gapped site this step is short. There is no path out, and no path in except the robots on the floor and the media port a signed update bundle arrives through. The point of doing it explicitly, even when the answer is nothing, is that the record shows the decision was made rather than forgotten.
The first robot on the pool
Late in the day, one robot from one vendor is pointed at the pool. It keeps its on-board model. It keeps every stop, speed limit, and motion limit exactly as the vendor delivered it. The only change is that for perception, decisions, and language it now asks the pool first and uses its own model when the pool does not answer within its budget.
The team watches that first fleet for a while. Not for performance figures, but for the plain behavior that matters on a floor: the robot asks, the pool answers, the robot moves, and when the team deliberately interrupts the pool the robot stops or falls back as it would have before the pool existed. That last test is the one the safety officer cares about, and it is run on purpose on day one.
What the site has at the end of the day
At the close of installation the site holds a pool in its own rack, a record of what each node attested, a signed list of the routes the pool may use, and one fleet asking it questions. The remaining fleets are added in the following days using the same steps, one vendor at a time, as described in adding a vendor's fleet to an existing pool.
The team that did the work is the team that will run it. Element 31 engineers leave behind the record and the routes, and the operator's automation team takes the pool into daily service, which is where day two begins.
Questions this raises
- Does the facility need a new network for the pool?
- No. The Grid serves robots over the facility's own network. The installation work is about deciding which segments the pool sees and which systems it may reach, not about pulling new infrastructure.
- Who is on the floor during installation?
- Element 31 engineers from E31 Consulting work alongside the operator's automation team, the systems integrator, and the robot vendors whose fleets will use the pool. The operator keeps authority over the floor throughout.
- Can robots keep working while the pool is installed?
- Yes. Robots keep their own on-board model for reflexes and fall back to it whenever the pool cannot answer. Pointing a fleet at the pool is additive; nothing on the robot is removed to make room for it.
KEEP READING