Decision models for the moment the robot gives up

Every robot has a moment where it gives up. The planner has looked at the scene, found no path it is confident in, and done the correct thing, which is to stop and wait for a person. On a busy floor that moment is the most expensive one in the robot's day. The person has to walk over, look, and decide, and the aisle is blocked until they do. Decision models on the pool are for exactly that moment.

The planner's edge

A robot's on-board planner is good at what it was built for. It routes around known obstacles, sequences known picks, and keeps to the paths it was taught. Its edge is the situation that fits none of its cases: two people and a pallet jack in the aisle it needs, a bin whose contents do not match the order, a doorway half-blocked by something it cannot classify.

At that edge the planner's options are to guess or to stop. Vendors, rightly, make it stop. The cost is that a floor with many robots has many stops, and each one pulls a person off their own work.

What the pool adds

A decision model on the pool has what the planner lacks: room for a larger model, context about the site and the task, and retrieval over the site's own documents. When the planner reaches its edge, the robot asks the pool. The pool weighs the scene as the perception models describe it, the task the robot is on, and the site's own rules, and returns a choice: wait, take the alternate route, set the item aside, call a person after all.

The answer has to arrive inside the robot's latency budget, and Substrate holds that budget as a hard line. A decision that arrives late is discarded, and the robot has already stopped. The pool turns some stops into continued work. It never turns a stop into motion the robot did not have time to check.

Decisions within bounds

A decision model is not free to choose anything. Site tasks are authored in Agency Studio, the task layer on the Grid, and each task is bounded: the zones a robot may enter, the speeds it may use, the distances it keeps, the stops it must respect. Tasks are versioned and approved by named roles before they run.

The decision model chooses within those bounds. If the alternate route leaves the approved zone, it is not an option the model can return. If setting an item aside is not part of this task's version, the model does not propose it. The boundaries are the site's, set by people with authority over the floor, and the model works inside them.

Safety is not a decision

None of this touches the robot's safety functions. Stops, speed limits, reflexes, and motion limits remain on the robot as its vendor built them, and the decision model has no path to them. A decision from the pool is a suggestion to the planner about what to do next within the task; the robot's own safety logic decides whether any motion is permitted at all.

That separation is what lets a site accept a decision model. The question of whether a robot may move is answered on the machine. The question of what it should do, given that it may, is the one the pool answers.

The record that makes the decision defensible

Every decision the pool serves is recorded: the robot, the task and its version, what the pool was shown, the model and its version, the choice returned, and the time. The record stays on the pool, inside the operator's network, and a run can be replayed from it.

This is what a safety officer needs when something on the floor was odd, and what an automation team needs when a decision was right but slow. The robot did something, and the site can say exactly why, from a record rather than a reconstruction. A Czar keeps that record for a small floor and a Czar Grid for a facility. For the record itself, see The record a pool keeps of every decision.