What compliance asks and what the record answers

Sooner or later a compliance team asks about the agent. Their questions are not new; they are the questions they ask about any process that reads records and takes actions. The difference on Czar is that the agent was built to leave answers behind, on the appliance, in a form someone can read without a translator.

What the agent read

The first question is usually about inputs: what the agent saw when it produced this draft, and whether it was allowed to see it. The run record holds the packet that arrived and the passages the agent drew on from the corpus. The bounds of the version that was live state which material the agent was permitted to read.

So the answer is in two parts, both on the record. Here is what was read for this run. Here is what this version was allowed to read at all. If the two disagree, the policy check in the record shows it, because each step records whether policy allowed it. Compliance does not have to take the desk's word for what the agent could see; the version states it.

What the agent decided

Compliance wants to know what the agent concluded and how that became an action. The record holds the draft: the reply, the categorization, the proposed entry. It holds the step at which the run waited and what the reviewer saw at that moment, which is the draft and what it used.

The agent did not decide to act. A person did. The record names the reviewer and holds their decision, approve or stop, in its place in the sequence. A compliance team that is used to asking who signed off gets a name.

Stopped runs are kept as carefully as approved ones. A compliance team often wants to see the cases where the process caught something, and the record holds the draft the reviewer rejected alongside the reason the run went no further. Those stopped runs are evidence that the waiting step works, not noise to be filtered out.

What the agent changed

The step that sends, spends, or changes a record is the one compliance cares most about. The record shows which tool was called, what was sent, and that the call followed the reviewer's approval. The system that received the call, the ledger or the records system, has its own entry, and the two agree.

Because the call travelled a declared route to a system the site already secures, the receiving system's own controls applied. Compliance can check the agent's record against the target system's record, both held by the site. If the two ever disagree, that disagreement is itself a finding the site can investigate from material it owns.

Who allowed any of this

Beyond individual runs, compliance asks about authority: who decided this agent could use this model, read this material, and call this system; who published the version that was live; who made this person a reviewer.

The appliance writes each of those down. The admin's decisions about models, tools, and who may publish are recorded with the admin's name. Publishing a version and pointing an address at it are recorded with the operator's name. Changing a role is recorded with who changed it. The agent's history is as legible as its runs.

Where the answers live

All of this is on the appliance. The run record, the version history, and the role changes stay on the rack in the customer's building. Answering a compliance question does not mean exporting logs to a vendor or asking a vendor to produce them. The site opens its own record.

This is also what makes the record something an auditor can read. It was written for a person following a sequence, not for a machine reconstructing one. Inputs, draft, decision, and call, with names where people decided, on hardware the site controls. For how the record is kept, see /resources/the-run-record-and-what-it-holds and /governance.