The safety officer and the task record

Safety officers are professionally unimpressed by demonstrations. A robot that performs well while the vendor is watching tells them little. They want to know what the machine does when the network drops, when a person walks into the zone, when the model is wrong, and they want to know it from a document rather than from a promise. An inference pool is new to most of them, and it needs to answer those questions on their terms.

It has two answers. The first is about where safety lives. The second is about what gets written down.

Safety is on the robot and stays there

The pool serves perception and decisions: what the robot is looking at, what it should do next. It does not serve stops. Speed limits, motion limits, protective stops, and reflexes stay on the robot as the robot vendor set them, and the pool has no path to change them. A Czar Grid serving a floor of robots from several vendors is serving several different safety designs, each one intact.

That makes the failure case simple. If the pool is late, the robot falls back to its own on-board model and does what it already knew how to do. If the pool is unavailable, the robot stops or continues on its own model according to its vendor's rules. The pool never substitutes a guess for an answer. A pool that fails leaves a robot that stops, not one that improvises.

For the safety officer this means the robot's safety case, the one the vendor supplied and the officer already reviewed, is unchanged by the pool. The pool added capability. It did not take on authority.

The task is written down before it runs

Agency Studio is where site tasks are authored, and a task there is not a script. It is a bounded thing. The zones the robot may enter. The speeds it may move at in each zone. The distances it keeps from people, from running equipment, from the line. The stops it observes and the conditions that trigger them. Those bounds are the plant's or the warehouse's statement of what the robot is allowed to be, and they are versioned.

A task does not run because it was written. It runs because a named role approved that version with those bounds. At most sites, the safety officer is one of those roles for any task that brings a robot near people. The approval is recorded with the version. Widening a zone or raising a speed creates a new version, and the new version needs its own approval. There is no quiet drift.

Every run is on the record

Every run of every task is recorded: the task version, the bounds in force, what the robot's cameras saw, what the pool decided, what the robot did, and where it stopped. The run is replayable. The record lives on the site's own hardware, inside the site's own network, and nothing in it leaves the building.

When something happens, the safety officer does not convene a meeting to reconstruct it. The officer pulls the run. A humanoid that stopped short of a person in an aisle shows exactly when the person entered the frame, what the pool returned, and when the robot's own stop engaged. A mobile robot that took an unexpected path shows whether the pool rerouted it and why. The question of what happened has an answer that does not depend on who was watching.

A record an auditor can read

The record is also what the safety officer hands to anyone else who asks. It shows which roles approved which task versions, which bounds were in force on a given shift, which model version the pool was running, and what each run did. Each node attests what it is running before it joins the Grid or accepts a task, and Watchman verifies the integrity of what is running, so the record's claim about the software is a verified one.

That is a record an auditor can read without anyone explaining it. It was produced in the course of the site's own work, on the site's own hardware, and it is complete without anyone having remembered to write anything down.

What the officer should ask for before the first run

Walk the fallback with each vendor, with the pool deliberately offline, and watch each robot stop. Read the attestation record for every node. Review the first task's bounds in Agency Studio before approving it, and confirm the approval is on record. Then, after the first shift, pull a run and replay it, so that the first time the record is read is not the first time it is needed.

For how these pieces come together in a bounded first step, see Running a humanoid pilot inside the plant segment. For the broader technical picture, see Technology.