The run record and what it holds
Every run on Czar leaves a record: what went in, what each step did, whether policy allowed it, and who approved. It stays on the appliance and an auditor can read it.
· 4 min read
IN SHORT
A run record on Czar holds the inputs that started the run, what each step did, the passages the agent read, the draft it produced, whether policy allowed each step, which reviewer approved or stopped, and the call that was made. It names the version that handled the run. The record is kept on the appliance and is something an auditor can read.
Automated work is hard to trust because it is hard to reconstruct. Something happened, a record changed, and the explanation is scattered across logs that were never meant to be read together. On Czar, every run of an agent writes one record, in sequence, on the appliance, and that record is built to be opened later by someone who was not there.
What goes in
The record begins with the inputs. The packet that arrived through the front door, as the agent received it. This is the starting point against which everything else can be checked.
Then the record holds what each step did. For a reading step, the passages retrieved from the material the agent may read. For a drafting step, the draft produced from those passages. For a waiting step, the decision and who made it. For a calling step, the call made and to which declared tool. Each step is written in the order it happened.
Alongside each step, the record notes whether policy allowed it. The version's bounds are checked as the run proceeds, and the check is written down. A step that policy did not allow does not happen, and the record shows that the agent reached that point.
The decision, the person, and the version
When a run reaches a waiting step, a reviewer sees the draft and what it used and approves or stops. The record holds that decision and the name of the reviewer who made it. This is the part of the record that answers "who said yes." There is no anonymous approval.
The decision sits in sequence between the draft and the call, so a reader sees exactly what the reviewer saw before they decided. Approvals by named roles describes the role; the record is where its work becomes permanent.
Each record names the version that handled the run. Because one version is live behind an address at a time, this name is unambiguous. A reader who wants to know what the agent was permitted to do opens that version and reads its bounds. The record and the version together give a complete account: here is what the agent could do, and here is what it did.
One sequence
Inputs, draft, decision, and call are one sequence someone can open tomorrow. This is the organizing idea. The record is not four separate logs that have to be correlated by timestamp. It is one object, in order, that reads from the packet arriving to the call being made or the run ending.
A reviewer can follow a live run as it proceeds, watching the sequence grow. Or they can open a finished run and read it from the start. The articles Following a live run and Opening a finished run the next morning describe both.
Where it lives
The record stays on the appliance. It is not sent to a vendor, not copied to a cloud, not aggregated somewhere the site does not control. The site reads it on its own hardware, under its own access rules. An auditor the site admits reads it there too.
This matters because the record is sensitive. It contains the packet, which may hold personal or commercial detail. It contains the passages, which are the site's own documents. It contains the draft and the decision. Keeping it on the appliance keeps all of that under the controls the site already has for the material it came from.
The appliance also records the acts that shape agents. Publishing a version, deploying it to an address, pointing an address back, and changing a role are each written down with who did them. Together with the run records, these form a complete history: how an agent came to be able to do what it does, and what it did.
What the record answers
A site with run records on Czar can answer the questions that matter about automated work. What arrived. What the agent read. What it drafted. Whether its version permitted each step. Who approved, by name. What call was made. Which version was live. All of it from one record on hardware the site owns. That is why the record is described as something an auditor can read: not because it carries a stamp, but because it is complete, ordered, and local. The governance page describes how the record fits with the roles and the bounds.
Questions this raises
- Who can read a run record?
- Reviewers for that agent can follow a live run or open a finished one. The site decides who else may read records, including an auditor it chooses to admit. The record is on the appliance, so access is governed by the site rather than by a vendor.
- Does the record include the passages the agent read?
- Yes. The passages the agent drew from are part of the record, alongside the draft. Someone opening the run sees what the agent read and what it wrote from that reading, which is the same view the reviewer had at the waiting step.
- What does the record show for a run that was stopped?
- The inputs, the passages, the draft, and the stop decision with the reviewer's name. No call appears, because none was made. A stopped run is as complete a record as an approved one; it simply ends at the decision.
KEEP READING