What does the robot vendor have to change?

It depends on the robot, but the list is shorter than most vendors expect, and nothing on it touches safety. The vendor keeps its on-board model, its stops, speed limits, reflexes, and motion limits, and its fleet software. What changes is the destination for the requests a robot cannot serve on its own: perception at floor scale, decisions that weigh the whole floor, language instructions. Those go to the pool in the building over the facility's network, inside a latency budget, with fallback to the on-board model when the pool does not answer in time.

What the vendor keeps

The robot's safety system stays on the robot exactly as the vendor shipped it. The pool never asks for authority over a stop or a speed ceiling, so the vendor does not revisit that behavior. The on-board model for reflexes stays, because it is also the fallback. The fleet software stays, because the pool serves inference to the fleet rather than replacing the thing that runs it.

The vendor also keeps its relationship with its customer. Under Facility Direct the building subscribes to the Grid and the vendor's fleet is one of the fleets it serves. Under Czar Chassis the vendor ships the same Grid under its own name with its own fleet, and the customer receives one system from one vendor, with Element 31 providing sustainment and attestation underneath.

What the vendor adjusts

The first adjustment is routing. A robot that today sends larger requests to the vendor's cloud, or does not make them at all because the round trip was too long, sends them to the pool instead. The pool is on the same network as the robot, which is what makes requests useful inside a task that the cloud could not serve.

The second is the latency budget. The vendor knows how long each of its robots can wait for an answer before it must act alone, and that budget, set per robot in Substrate, is what triggers fallback. Setting it well is the vendor's expertise applied to the pool.

The third is fallback itself. Most robots already handle a missing answer from a remote service by doing something safe. The pool relies on that behavior and makes it the normal case for a miss rather than an exception. The vendor confirms on the floor that its robot does what it should when the pool is silent.

How the work is done

None of this is done by sending the vendor a document. E31 Consulting puts Element 31 engineers on site with the operator's automation team, the integrator, and each robot vendor. Together they connect the fleet to the pool, set the budgets, exercise fallback, and author the site tasks in Agency Studio that involve the vendor's robots, bounded by zones, speeds, distances, and stops and approved by named roles.

The vendor also gains something: a pool that serves models its robot could not carry, on a site whose feeds and captures do not leave, and a record of every decision the operator holds. For a vendor whose customer has been asking why the robot needs a cloud, the answer becomes that it does not.

The Czar Grid page covers the pool from the building's side. Can one pool serve robots from different vendors covers what happens when several vendors share it.