Changing a role and leaving a trace

An approval carries a name. A publication carries a name. A deployment carries a name. For any of those names to mean something later, the site has to be able to say that the person was entitled to act at the time. On Czar, roles are assigned by the admin, and every change to who holds a role is written down with who made it and when.

The four roles, briefly

The operator composes an agent, publishes versions, and turns the live address on or off. The developer describes the same agent as a file. The reviewer sits on the waiting steps and approves or stops. The admin decides which models are available, who may publish, which systems are tools, and who holds each role.

Each role is assigned per agent, so a person may be reviewer for one agent and operator for another, or hold no role at all for a third. The admin makes these assignments. The article What the admin decides covers the admin's wider responsibilities.

What a role change is and why it is recorded

Granting a role: this person may now act as reviewer for this agent. Removing a role: this person may no longer act as operator for that agent. Each is a single administrative act. The admin performs it, and the appliance records it with the admin's name and the time.

The record is an entry in the role history for that agent. Over time the history becomes a list: who was granted what, who was removed from what, by whom, and when. It reads like the deployment history for an address, and it serves the same purpose.

The reason is attribution after the fact. A run record names the reviewer who approved. A publication record names the operator who published. Those names answer "who did this." The role history answers the next question, "were they allowed to." A reader who sees that a particular person approved a run can check that the person held the reviewer role for that agent at that time, and see which admin granted it.

Without the role history, the names in the other records would float free. With it, every consequential act traces to a person, and every person's entitlement traces to an admin's decision.

Changes affect the future, not the past

Removing someone's reviewer role stops them approving future runs. It does not alter the records of runs they already approved. Those records keep the name, because that is who decided at the time, and the role history shows that the person held the role then.

The same holds for operators who lose the right to publish. The versions they published remain published, with their name on them. The role history shows when their right ended. An auditor reading the versions sees who published each one and can confirm they were entitled to.

This is the right behavior for a record. A record that changed when roles changed would not be a record.

The common sequence

Someone joins the desk and is to become a reviewer. The admin grants the reviewer role for the relevant agent. The entry is written. From that moment the person can act on waiting runs, and their name appears on the decisions they make.

Someone moves to another part of the site. The admin removes their roles for the agents they no longer work with. The entries are written. Their past decisions and publications remain, named, in the records. Their future acts on those agents are not possible.

Someone is to start publishing as well as reviewing. The admin grants the operator role alongside the reviewer role. Both grants are recorded. The site has decided, deliberately and visibly, that this person may both compose the agent and sit on its waiting steps. Approvals by named roles describes why that combination is a decision rather than a default.

Reading the history

The role history for an agent is read alongside its deployment history and its run records. Together they answer: which version was live, who pointed the address there, who was allowed to publish it, who approved each run under it, and who had made each of those people able to act. Every link in that chain has a name and a time.

For a site that must explain its automated work to someone outside the desk, this is what makes the explanation complete. Not only what the agent did, but who was in a position to let it, and who put them there. The run record and what it holds covers the first part of that chain.

Changing a role on Czar is deliberately not a quiet act. It leaves an entry that cannot be removed, next to the other entries that describe how the agent came to do what it does. That is what lets a site assign roles with confidence: every assignment can be looked up, and every act performed under it can be traced back. The governance page describes the roles together.