Approvals, named roles, and versions

A floor with robots from several vendors needs one place where the question "what is this robot allowed to do here" has a clear answer. On a Czar Grid that place is Agency Studio, and the answer takes a specific form: a versioned task, bounded in plain terms, approved by named people, with every run recorded against it. This article describes how those pieces fit and what an operations team does with them day to day.

Tasks are authored and versioned

A site task is written down. It describes what a robot should do in this building: carry from here to there, pick from this face, inspect this bay, escort this cart. The author is usually someone on the automation team or the integrator, working with the vendor whose robots will run it.

Once written, the task has a version. Any change produces a new version; the old one does not disappear. This matters more than it first appears. On a floor where tasks are tuned often, the version is the only reliable way to answer which task a robot was running at a particular time, and a record that says "the picking task" without a version is a record that cannot be relied on.

Bounds are part of the version

Each version carries its bounds: the zones a robot may enter, the speeds permitted in each, the distances it must keep from people and structures, and the places it must stop. These are written in the language of the floor, not the language of the model, and they are the part of the task the safety officer reads most closely.

Bounds sit above the robot's own safety, not in place of it. Every stop, speed limit, reflex, and motion limit the vendor built into the machine remains on the machine, untouched by any task. A task bound can only be more restrictive than what the robot would do on its own. If the pool serves a decision and the task bound would not allow it, the bound governs; if somehow both were wrong, the robot's own limits still govern. The layers are arranged so that the safest one is always the lowest.

Approval by named roles

A version does not run until it is approved, and approval comes from named roles. The site chooses who they are. The automation lead and the safety officer are nearly always among them, because one knows the floor's operations and the other owns its safety. Where a task involves a particular vendor's fleet, that vendor's representative is often added. Where an integrator maintains the routes and fleet connections, the integrator is often added too.

The word named is doing work. An approval from a person is a decision someone can be asked about. An approval from a group alias is not. Agency Studio records the approver with the version, so later the record shows that this version of this task was approved by this person on this occasion, and that the version then ran.

What approvers actually do is read the difference. Approving a version means looking at what changed from the one running now, walking the bounds against the floor as it is today, and signing or refusing. On a healthy site refusals are common and unremarkable; they are how a task gets better before it reaches a robot.

Every run is recorded against the version

When a version runs, Agency Studio records the run: the robot, the version, the bounds in force, what happened step by step. The run is replayable. Substrate's record of the decisions the pool served during the run sits beside it, so a step can be traced to the perception and decision outputs the robot was given at the time.

For the operations team, this closes the loop. A question about a robot's behavior becomes a question about a run, which becomes a question about a version and its approval. Nobody has to reconstruct intent from memory. The run record and the next morning describes how the team reads this each day.

Why this is an operations topic and not a paperwork topic

It would be possible to treat versions and approvals as paperwork ceremony. Sites that do so get little from them. Sites that treat them as the operating model get a floor where every change to what a robot may do passed through a named person who read it, where every run can be replayed, and where a mixed fleet from several vendors is governed in one place by one set of people.

That is a different kind of floor from one where tasks live in a vendor's cloud and change when the vendor pushes. On a Czar Grid the task library, its versions, its approvals, and its runs are the site's own, on the site's own hardware, and nothing about them leaves the building. The approvers are people who walk the floor. Who operates the pool describes how those roles are usually filled.