Opening a finished run the next morning
A question comes in about something the agent did yesterday. The reviewer opens the run and reads it from the packet to the call, with every decision named. No reconstruction.
· 4 min read
IN SHORT
A finished run on Czar can be opened at any later time and read as one sequence: the packet that arrived, the passages the agent retrieved, the draft it wrote, whether policy allowed each step, who approved or stopped and when, and the call that was made. It names the version that handled it, so the bounds in force can be looked up too. Nothing has to be reconstructed.
A claimant calls about a letter. A manager asks why a request was routed the way it was. An auditor asks how a particular record came to be changed. In each case the answer lies in something an agent did some time ago, and someone has to explain it. On Czar, the explanation is the run record, and opening it is a matter of finding the run and reading.
Each run is kept on the appliance, named by the agent, the version that handled it, and when it ran. A reviewer looking for the run that produced a particular letter finds it by the packet that started it or by the call that ended it. There is no correlating of separate logs. The run is one object.
Reading from the top
The record opens with the inputs: the packet as it arrived through the front door. The reader sees what the agent was given, which is the first thing most questions turn on. If the packet was incomplete or unusual, that is visible at once.
Next come the steps in order. The reading step shows the passages retrieved from the material the agent may read. The reader sees which clauses, which history, which procedure the agent drew on. The drafting step shows the draft produced from those passages. The reader can compare the draft against the passages and judge whether it follows.
Alongside each step, the record notes whether policy allowed it. A reader sees that the version's bounds were checked and held.
The decision and the version
Then the waiting step: the draft and its sources as the reviewer saw them, the reviewer's decision, and the reviewer's name. If the question is "who approved this," the answer is on this line. If the question is "did they have what they needed to approve it," the reader is looking at exactly what the reviewer had.
Then the call, if there was one. Which declared tool was called and what the call did. Or the end of the run, if the reviewer stopped it. Approvals by named roles describes how the decision comes to carry a name.
The record names the version that handled the run. Because one version is live behind an address at a time, this is unambiguous. A reader who wants to know what the agent was permitted to do opens that version and reads its bounds: which models, which material, which tools, where it had to wait, what it could never do. The record says what the agent did; the version says what it could have done. Together they are the full account.
Answering the common questions
Why did the agent write this. The passages it read and the draft it produced are side by side. The reader sees the reasoning's raw material.
Who let this happen. The reviewer's name is on the decision.
Was the agent allowed to do this. The policy check against each step is recorded, and the version's bounds are a step away.
What did the agent actually change. The call is recorded, with the tool it reached.
Did anything leave the building. Nothing did. The record shows retrieval on the appliance and a call to a declared route. There is no step that reaches a vendor's cloud, because there is no such step in any version.
Reading several runs together
An operator who opens several finished runs under the same version sees patterns. Reviewers stopping runs on the same kind of packet. Drafts that consistently cite one clause when another applies. A waiting step that reviewers reach without enough context. These are design signals, and the fix is to adjust the canvas and publish a new version.
This is a quieter use of the record than audit, but a frequent one. The record of what the agent did is also the record of how the design is performing, and operators read it that way. The run record and what it holds lists everything the record contains.
Why this is possible
The run record was written as one sequence, on the appliance, with the decision and the person in it, at the time of the run. Nothing has to be assembled later. Nothing has to be requested from a vendor. The reviewer who opens it the next morning, or the auditor who opens it much later, reads the same record that was written while the run happened. That is what makes the explanation a matter of reading rather than reconstruction. The governance page describes the record alongside the roles that produce it.
Questions this raises
- How long are finished runs kept?
- The record stays on the appliance under the site's own retention decisions. It is not sent anywhere and is not subject to a vendor's retention policy. The site decides how long to keep records and who may read them.
- Can an auditor open runs without a reviewer present?
- The site decides who may read records, and can admit an auditor to read them directly on the appliance. The record is designed to be read by someone who was not there, so a reviewer does not need to narrate it.
- What if the question is about a run that was stopped?
- The record for a stopped run shows the inputs, the passages, the draft, and the stop with the reviewer's name. There is no call, because none was made. The reader can see what the reviewer saw and judge whether the stop was right.
KEEP READING