What a robot vendor keeps when a site adds a pool
A vendor's first question about a facility pool is usually what it takes away. The answer is nothing the vendor built. Here is the list of what stays the vendor's, and what the vendor gains.
· 4 min read
IN SHORT
A robot vendor keeps everything it built when a site adds a Czar Grid: the robot, the controller, the on-board model, the safety case, the fleet software, and the customer relationship. The pool serves perception and decisions beside the vendor's system, connects to the vendor's fleet software only if the site declares that route, and can be shipped by the vendor under its own name as Czar Chassis.
When a customer tells a robot vendor that the building is installing an inference pool, the vendor's first instinct is defensive. Someone else's rack is about to sit between the vendor's robots and the vendor's cloud, and the vendor would like to know what it is about to lose. The honest answer is that it loses nothing it built. This article is the inventory of what stays the vendor's, written so a vendor can check it line by line.
The robot and its controller
The body is the vendor's. The joints, the drive, the gripper, the sensors, and the controller that runs them are untouched by a Czar Grid. The pool serves perception and decision models over the facility's network; it does not reach the controller and does not change the robot's on-board model.
The on-board model stays too. Reflexes, balance, obstacle stops, slip detection: all the fast loops the vendor tuned stay where the vendor put them, running at the speed they ran before. The pool is where the robot sends the questions the on-board model is too small to answer well. When the pool does not answer in time, the robot falls back to that on-board model exactly as it would without a pool.
The safety case
This is the one vendors care most about, and it is the one the pool is most careful with. Stops, speed limits, reflexes, and motion limits stay on the machine as the vendor validated them. The pool holds none of them. It is not in the safety loop, cannot be configured into it, and does not need to be reviewed as part of it beyond confirming that it is absent from it.
When the pool is late or absent, the vendor's robot stops or runs on its own model; it never acts on a guess. The safety argument the vendor made for its robot before the pool arrived is the same argument after. Why safety stays on the robot explains the reasoning in full.
The fleet software
The vendor's fleet software keeps doing what it did. It dispatches the vendor's robots, tracks them, schedules charging, and reports to the vendor's dashboard. The pool does not replace it, and the two do not have to be integrated for the robots to use the pool.
Whether the pool is allowed to talk to the fleet software at all is the site's decision. Substrate's governed connectivity, Local Bridge, permits only the routes the site declares and denies egress by default. A site may declare the vendor's fleet software as a route, in which case the two systems can exchange what the site allowed. A site may declare nothing, run the pool air-gapped, and let the robots use it over the floor network alone. Either way, the vendor's software is the vendor's. The article on connecting a vendor's fleet software to the pool covers the practicalities.
The customer
The vendor keeps its customer. There are two routes to a Grid, and in neither does Element 31 step between the vendor and the building. Under Facility Direct the building subscribes to the Grid itself, and the vendor's robots use it as they would any facility system. Under Czar Chassis the vendor ships the Grid under its own name, bundled with its fleet, and the customer receives one system from one supplier. Element 31 provides sustainment and attestation underneath.
Czar Chassis is not a different machine. It is the same Czar, the same Grid, and the same Substrate, with the vendor's name on the proposal. A vendor who ships it is offering its customer a fleet that can call on models larger than the body can carry, without the vendor running a cloud to serve them. For some vendors that is a cost they are glad to put down. How to buy sets out both routes.
What the vendor gains
Nothing on the list above moved. What changed is the ceiling. A vendor's robot no longer has to carry every model it might need, and it no longer has to send the customer's camera feed out of the building to reach a larger one. The large perception, decision, and language models run in the customer's rack, and the vendor's robot asks them over the customer's network.
The vendor also gains a floor that teaches itself. When the site adapts the shared model on its own captures, the vendor's robots get better at that site without the vendor shipping a model update. And when something goes wrong, the record on the Grid shows what the robot asked, what the pool answered, and what the robot did, which is a better starting point for a support conversation than a log on a distant server.
The pool is beside the vendor's system, not inside it. That is the whole design, and it is what makes it safe for a vendor to say yes to.
Questions this raises
- Does the pool compete with the vendor's cloud?
- The pool runs the models that are too urgent to send away and keeps the site's captures inside the building. A vendor's cloud can still run whatever the site chooses to declare a route to. The site decides which, and that decision is per site, not per vendor.
- Does the vendor have to support the pool?
- Element 31 provides sustainment and attestation for the Grid underneath whoever ships it. If the vendor ships it as Czar Chassis, the customer sees one system under the vendor's name, and Element 31 sustains the pool beneath it.
- Can the vendor stop its robots from using the pool?
- The robot asks the pool only where the vendor's software is built to ask. What a vendor's robots send to the pool, and what they do with the answer, remains the vendor's design. The pool serves the questions it is asked within each robot's latency budget.
KEEP READING