Skip to content
ELEMENT 31

Fallback to the robot

Fallback to the robot is the rule that when the pool cannot answer within a robot's latency budget, the robot acts on its own on-board model, and if that cannot proceed, it stops.

· 2 min read

IN SHORT

Fallback to the robot is the rule that when the inference pool cannot answer within a robot's latency budget, the robot acts on its own on-board model, and if that model cannot proceed, the robot stops. The pool is never on the robot's safety path, so the worst case for the pool is a robot behaving as it would with no pool at all.

Fallback to the robot is the rule that when the inference pool cannot answer within a robot's latency budget, the robot acts on its own on-board model, and if that model cannot proceed, the robot stops. The pool is never on the robot's safety path.

Why it matters

Any shared system can be slow or unavailable at some moment. The design question is what a robot does in that moment. A robot that keeps moving on a stale or guessed answer is a hazard; a robot that stops is a delay.

Fallback makes the answer a delay. The robot keeps the model it would have carried anyway, for reflexes and local awareness, and it uses that model whenever the pool is late. Its stops, speed limits, and motion limits are on the machine as the vendor shipped them, and they do not depend on anything in the rack.

That lets a safety officer reason about the floor without reasoning about the pool. The worst case for the pool is the robot behaving as it would with no pool at all.

How it works at Element 31

Substrate holds each robot to its own latency budget on the Czar Grid. If the pool cannot deliver inside that budget, the robot does not receive a late answer. It falls back to its on-board model for that decision and continues to ask the pool for the next.

The pool serves perception and decisions; it does not serve safety. Element 31 does not move stops, limits, or reflexes into Czar, and Agency Studio bounds what a site task may ask of a robot rather than overriding what the robot refuses to do.

Fallback is the same on every posture. An air-gapped Grid and a connected Grid both sit behind the robot's own limits. A Grid delivered as Czar Chassis behaves exactly as one delivered through Facility Direct.

The run record captures when fallback happened. An operator reviewing a shift can see which decisions the pool served and which the robot made alone, which is useful to the integrator sizing the pool and to the safety officer reviewing an event. The Czar Grid page describes how the pool and the robot divide the work.

Questions this raises

Does fallback mean the robot keeps working without the pool?
It keeps working to the extent its on-board model allows, which covers reflexes and local awareness. Work that needs the heavier perception or decision models waits until the pool answers. If the robot cannot proceed safely, it stops.
Why is safety kept off the pool entirely?
So a safety officer can reason about the floor without reasoning about the pool. If stops and limits lived in the rack, a slow or unavailable pool would be a hazard. Kept on the robot, a pool failure is only a delay.
How does an operator know when fallback happened?
The run record captures it. Reviewing a shift, the operator can see which decisions the pool served and which the robot made alone, which helps the integrator size the pool and the safety officer review an event.

KEEP READING

Related.