Approvals by named roles
When an agent waits, a reviewer approves or stops, and the decision carries that person's name. Approval on Czar is a role with a record, not a button anyone can press.
· 4 min read
IN SHORT
On Czar, the step that sends, spends, or changes a record waits for a reviewer, a named role the admin assigns. The reviewer sees the draft and what it used, approves or stops, and the run continues on that decision. The decision is attributed to the person and kept in the run record, so every consequential act traces to someone who said yes.
An approval only means something if someone specific gave it. "The system approved it" is not an answer anyone can act on later. On Czar, approvals are made by a named role, the reviewer, held by people the admin has assigned, and every approve-or-stop decision is written into the run record with the name of the person who made it.
The reviewer role
Four roles touch an agent on the appliance. The operator owns the outcome and composes, publishes, and turns the live address on or off. The developer describes the agent as a file. The admin decides what is available and who may do what. The reviewer sits on the steps that wait.
The reviewer's job is narrow. When a run reaches a waiting step, the reviewer is shown the draft, the passages it was drawn from, and the call the agent proposes to make. They approve or they stop. That is the whole role. It is narrow on purpose, because a narrow role is one a site can assign carefully and audit cleanly.
The admin assigns the reviewer role, per agent, to specific people. A claims agent might have reviewers drawn from the senior adjusters. An intake agent might have a different set. One person can be reviewer for several agents, and several people can be reviewers for one.
The admin's assignment is a recorded act. Changing a role is written down with who did it, so the site can later answer who was able to approve runs for a given agent during a given period. The article Changing a role and leaving a trace covers that record.
What the reviewer decides
Approve or stop. If approved, the run continues to the allowed call, and the call is made. If stopped, the run ends there and nothing is sent, spent, or changed. The reviewer does not edit the draft or redirect the run. Their decision is binary so that it is unambiguous on the record.
A stop is not a failure. It is the reviewer doing their job. The packet goes back to the desk's usual handling, and if the stop reveals a flaw in the agent's design, the operator adjusts the canvas and publishes a new version. Many stops on the same kind of packet are a signal worth reading.
What the record keeps
Each run record includes who approved when a person had to. The decision is attributed to the reviewer by name and placed in sequence with the inputs, the passages, the draft, and the call. Someone opening the run later sees exactly what the reviewer saw and what they chose.
This gives the site a clean chain. The agent drafted from these passages. This person approved. This call was made. If the outcome is questioned, the record answers without anyone having to remember. The run record and what it holds describes the record in full.
Why operator and reviewer are separate
The operator who drew the agent is the person most likely to trust it. That is a reason to keep approval in a different role by default. The admin can give one person both roles where the desk is small or the stakes are low, but the platform does not assume it. Separating the roles means that, unless the admin decides otherwise, the person who built the agent is not the person who signs off on its actions.
This mirrors how most desks already work. The person who prepares a determination is often not the person who signs it. The agent takes the preparing role, and the reviewer keeps the signing role.
Several reviewers, one decision
When several people hold the reviewer role for an agent, any of them can act on a waiting run. Whoever acts is the one named. There is no ambiguity about which of the several reviewers approved, because the record names the one who did. A site can arrange its reviewers so that waiting runs are picked up promptly without losing the attribution of each decision.
Every consequential act an agent takes on Czar traces to a person who saw the draft and its evidence and said yes, by name, in a record the site keeps on its own hardware. The people who can say yes are chosen by the admin and the choice is recorded. That is what approval by named roles means in practice. The governance page describes how the reviewer fits with the other roles.
Questions this raises
- Can the operator approve their own agent's runs?
- Only if the admin has also given them the reviewer role for that agent. The roles are separate on purpose. An operator composes and publishes; a reviewer sits on the waiting steps. One person can hold both roles if the admin decides so, and that assignment is recorded.
- What happens when the reviewer stops a run?
- The run ends without making the call. The stop is written into the record with the reviewer's name and the draft they saw. The packet is handled by the desk's usual means, and the operator may adjust the design and publish a new version if the stop points to a flaw.
- Can approval be delegated to a group?
- The admin decides which people hold the reviewer role for a given agent. Several people can hold it. Whoever acts on a waiting run is the one named in the record, so even with several reviewers, each decision traces to one person.
KEEP READING