How a pool falls back to the robot

A pool is a shared resource, and shared resources are sometimes busy, sometimes updating, and sometimes unreachable. A robot in an aisle cannot care about any of that. It needs to know what to do in the next moment, and it needs that to be true whether or not the rack answers. Fallback is the arrangement that makes it true.

Fallback belongs to the robot

The first thing to understand is that fallback is not something the pool does. It is something the robot does. Every robot on the floor arrived with its own on-board model for reflexes, known routes, and known picks, and with its vendor's safety functions: stops, speed limits, motion limits. None of that was removed when the pool was installed.

The pool's answers are additional. When a perception or decision answer arrives within the robot's latency budget, the robot uses it and does something it could not have done alone. When no answer arrives in time, the robot does what it would have done before the pool existed. From the robot's point of view, a pool that fails looks like a pool that was never there.

Why safety never moves

It would be possible, in principle, to put a robot's safety logic on a pool. It would be a mistake, and Element 31 does not do it. Stops, speed limits, reflexes, and motion limits stay on the robot as its vendor built them. The pool serves perception and decisions and is not in the path of anything that keeps a person safe.

The consequence is a precise statement about failure. A pool that fails leaves a robot that stops, not one that guesses. There is no state of the pool, busy, degraded, unreachable, mid-update, in which a robot's stop is late or its speed limit is lifted. Those are decided on the machine, by logic the pool cannot reach.

A late answer is no answer

Inside the pool, Substrate treats each robot's latency budget as a hard line. If an answer cannot be produced inside the budget, it is not sent. A late answer describing a scene that has since changed is worse than no answer, because the robot has already acted and the stale answer could contradict what it now sees.

So the pool discards the late result and records the miss. The robot is never put in the position of reconciling two answers from two moments. It has the on-board answer it already acted on, and nothing else arrives.

What fallback looks like on the floor

On a mobile robot, fallback usually looks like a slower approach or a stop at the edge of what the on-board model is sure about, followed by a resume when the pool answers again. On a pick arm it looks like a pause above the bin. On a humanoid it looks like the conservative path the vendor defined for uncertainty. In each case the robot is less capable for a moment and no less safe.

For the automation team, fallback should be rare enough to notice and recorded well enough to explain. A robot that hesitates in the same aisle every afternoon is telling the site something about that part of the network or about demand at that hour.

The record of the miss

Every missed budget is written to the record on the pool, with the robot, the kind of request, and the time. That record stays on the operator's hardware like everything else the pool holds. It is the first thing to read when a floor feels hesitant, and it is the evidence for a sizing conversation: if misses cluster at the busiest hour, the pool is short; if they cluster in one area, the network is.

A Czar Grid reduces misses by spreading demand across nodes and by letting one node update while the others serve. But the fallback arrangement is the same on one Czar as on a Grid. The robot keeps its own model, keeps its own safety, and acts on what it has. For the budget that fallback protects, see The latency budget for a robot served from the rack.