What happens when the pool is unreachable?
The robot falls back to its on-board model. It keeps reflexes, stops, and motion limits, finishes what it can alone, and waits. Nothing on the floor depends on the pool to be safe.
· 3 min read
IN SHORT
The robot falls back to the model it carries on board. Each robot has a latency budget held by Substrate, and when the pool cannot answer inside it the robot stops waiting and acts on what it has: reflexes, stops, speed limits, and simple motions. Work that needs the pool pauses; safety does not. When the pool returns, robots resume using it.
It depends on what the robot was asking for, but the shape of the answer is always the same: the robot stops waiting and acts on what it carries. Every robot on a Czar Grid keeps its own on-board model for reflexes, stops, speed limits, and motion limits. When the pool cannot answer in time, the robot uses that model, does what it can safely do alone, and waits for the pool to come back. The floor loses capability for a while. It does not lose safety.
How the robot knows the pool is gone
A robot does not wait indefinitely. Substrate, the serving system on the Grid, holds a latency budget for each robot, which is the longest that robot can afford to wait for an answer before it must act on its own. A humanoid mid-step has a shorter budget than a crane planning its next lift. The budget is set per robot, not per pool.
When an answer does not arrive within the budget, the robot treats that as a miss and falls back. It does not need to know whether the cause was a dead switch, a node pulled for an update, or a pool that was simply busy. From the robot's side those are all the same event, and the response is the same: use the on-board model.
What fallback looks like on the floor
A mobile robot that was relying on floor-scale perception slows and navigates on its own sensors, or holds position if its path is uncertain. A pick arm finishes the motion it has already committed to and pauses before the next pick. A humanoid completes a simple step or stands still. Automated vehicles on a terminal continue on their own guidance within their own limits.
None of those behaviors came from Element 31. They are what the robot vendor designed the machine to do without outside help, and the pool never changed them. That is the point of keeping safety on the robot: the worst case for a pool outage is a floor that goes quiet, not a floor that goes wrong.
Work that genuinely needs the pool waits: a language instruction from a supervisor, a decision that weighs the whole queue, a perception task beyond the robot's own cameras. An operator will see the fleet slow down. The operator will not see the fleet improvise.
How the pool comes back
A Czar Grid is several Czars sharing the work, so losing one node is not losing the pool. The remaining nodes keep serving, and robots whose requests were on the lost node are served by the others within their budgets where capacity allows. A single Czar on a small floor has less to fall back on, which is one reason a growing site joins more than one.
When a node returns, it attests what it is running before it rejoins the Grid. Robots do not need to be told; their next request is simply answered in time, and they resume using the pool. The record of decisions on the Grid shows the gap, so the automation team can see when the pool stopped answering and when it started again.
The Czar Grid page covers how nodes are joined, and the safety question explains why the stop never depended on the pool in the first place.
Questions this raises
- Does a robot need an internet connection to fall back?
- No. Fallback is local to the robot. It happens when the pool inside the building does not answer within the robot's latency budget, and it uses the model the robot already carries.
- If one Czar in a Grid fails, is the whole pool unreachable?
- No. A Czar Grid is several Czars sharing one pool, so the remaining nodes keep serving. Robots whose requests were on the lost node are served by the others where capacity allows, and the returning node attests before it rejoins.
- Can a robot keep working during a pool outage?
- It can do what its on-board model supports: careful motion, finishing a committed step, holding position. Work that needs floor-scale perception, a language instruction, or a decision across the whole queue waits until the pool answers again.
KEEP READING