Skip to content
ELEMENT 31

Run record

A run record is the stored, replayable account of one execution of a site task on a Czar Grid: the task version, who approved it, what the robot did, and which decisions the pool served.

· 2 min read

IN SHORT

A run record is the stored, replayable account of one execution of a site task on a Czar Grid: which task version ran, who approved it, what the robot did, and which decisions the pool served along the way. It is written as the run happens, stays on the operator's hardware inside the building, and gives the safety officer, the integrator, and the vendor one account to read.

A run record is the stored, replayable account of one execution of a site task on a Czar Grid: which task version ran, who approved it, what the robot did, and which decisions the pool served along the way. It stays on the operator's hardware.

Why it matters

When a robot does something unexpected on the floor, the first question is what happened, and the second is what it was told. On many sites the answer is assembled afterward from vendor logs, camera footage, and recollection, each in a different format and each held by a different party.

A run record is the answer kept in advance. It is written as the run happens, it is tied to the version of the task and the approvals behind it, and it can be replayed. The safety officer, the integrator, and the robot vendor read the same account.

It also closes the loop on the pool itself. The record shows which decisions the pool served, which the robot made alone after falling back, and how the task's bounds were applied.

How it works at Element 31

Agency Studio records every run of every site task. The record includes the task version, the named roles who approved it, the bounds in force, and the sequence of what the robot did. Substrate's evaluation output and its record of served decisions sit alongside.

The record never leaves the building. Like camera feeds, captures, and adapted model weights, it stays on the operator's hardware inside the operator's network, on an air-gapped site and on a connected one. Nothing about the record depends on a path out.

Replay is on the Grid. An operator can step through a run after the fact to see what the task asked, what the pool answered, and where the robot fell back to its on-board model. That is useful for an incident review, for an integrator tuning a task, and for an auditor who wants something to read rather than something to be told.

The run record is the same whether the Grid was subscribed through Facility Direct or arrived under a vendor's name as Czar Chassis. Element 31 sustains the layer that keeps it, and the operator owns what it contains. The Technology page describes the record alongside the rest of the stack.

Questions this raises

What does a run record contain?
The task version, the named roles who approved it, the bounds in force, the sequence of what the robot did, and the decisions the pool served. Substrate's evaluation output sits alongside it.
Can a run be replayed?
Yes, on the Grid. An operator can step through a run after the fact to see what the task asked, what the pool answered, and where the robot fell back. It is meant for incident review, task tuning, and anything an auditor wants to read.
Does the run record ever leave the site?
No. Like camera feeds, captures, and adapted model weights, it stays on the operator's hardware inside the operator's network. Nothing about keeping or replaying it depends on a path out of the building.

KEEP READING

Related.