The record a pool keeps of every decision

A robot did something on the floor, and someone wants to know why. That sentence is the whole justification for the record. A pool that serves perception and decisions to every robot in the building is in a position to answer it, from evidence, for every robot, every time. The record is how.

What is written

For every answer the pool serves, Substrate writes an entry: which robot asked, what kind of request it was, what the pool was shown, which model answered and which version of it, what was returned, and when. For every request the pool could not answer within the robot's budget, it writes the miss, with the same robot, request, and time.

For site tasks authored in Agency Studio, the entry also carries the task and its version, so a decision can be read against the boundaries it was made within. Every run of a task is recorded and can be replayed from the record.

Where it lives

The record stays on the pool, on the operator's hardware, inside the operator's network. It does not go to Element 31. It does not go to a robot vendor's cloud. On an air-gapped site there is no path for it to go anywhere; on a connected site the only routes out are the ones the site declared, and the record is not on them.

This follows from the general rule that nothing leaves the building: camera feeds, captures, task records, adapted model weights, and the record of every decision all stay. The record is the most sensitive of these, because it is the one that says what every machine on the floor was told, and it is held to the same standard as the rest.

Reading it after an incident

The first reader of the record is usually a safety officer after something odd happened. A robot paused in an aisle, or took a route no one expected, or set an item aside. The record shows what the robot's cameras showed the pool, what the perception model said was there, what the decision model returned, and what the task permitted. If the robot fell back because the pool was late, the record shows that too.

The record is written to be read by that person, not by a specialist. Where the site runs a language model on the pool, the record can be rendered as a plain explanation, but the entries underneath remain available in full. An auditor can read them as well; the record is something an auditor can read, which is a different thing from a claim about any particular audit.

Reading it before anything happens

The record's second life is operational. Missed budgets clustered at one hour say the pool is short at that hour. Missed budgets clustered on one part of the floor say the network is tight there. Decision requests that always return the same choice for the same scene say a task boundary could be widened or a planner updated. The record is the first thing an automation team reads when a floor feels hesitant, and it is the evidence that starts a sizing conversation.

The record also feeds adaptation. The captures the site's robots have made are what a perception model is fine-tuned on, on the pool, with nothing leaving. And the record is the evaluation set: an adapted model is checked against what the floor actually saw before it is allowed to serve, and that check is itself recorded.

One record for the whole floor

A floor with robots from several vendors has, without a pool, several records, each in a vendor's format, each in a vendor's system, some of them in a vendor's cloud. Reconciling them after an incident is a project. A pool that serves every robot keeps one record for every robot, in one place, in one form, on the site's hardware.

That is as true of a single Czar as of a Czar Grid. On a Grid, the record spans the nodes; the site reads one record, not one per node. For what the robots' decisions are bounded by, and so what the record is read against, see Decision models for the moment the robot gives up.