What the record guarantees
The properties that hold by construction, and the three kinds of record that carry three different strengths.
An auditor's first question about any trail is not what it contains. It is what would have had to happen for this trail to be wrong. This page answers that, and it separates the properties that are enforced from the properties that are merely intended — because conflating those two is how a control you believe in turns out not to exist.
Properties that hold by construction
Each row below is a property of how the product is built, not a policy someone is asked to follow.
| Property | What it means when you are reading the record |
|---|---|
| No part of the product can approve | The engine moves work and writes down decisions. It never judges. There is no path through the software that accepts, merges or promotes anything, so an advancement you find in the record was a human act or it is not there. |
| A decision cannot be left to default | A gate decision has no default value. The inputs are required and come from a closed set of words, so there is nothing for a decision to drift into and no such thing as an unfilled decision that still counted. |
| Silence is never consent | No timeout anywhere grants an approval. Delegated acceptance exists, but only under a named policy owned by a named human and scoped to explicit classes of change — never to a clock. |
| Suggestion and decision are separate events | A consultation, whether by a person or by a model, is recorded as advice. The decision is the human's own act, and an override of the advice is itself recorded. The two can never collapse into one entry, so the record shows what was recommended and what was decided. |
| "Merged" is observed, never granted | The product does not declare a change merged. It observes a real merge in your own version control. A merged state in the record therefore has a commit behind it. |
| A decision out of order is refused, and nothing is written | An attempt to decide before what the stream still owes has been supplied is refused, and the refusal writes no decision. There is no partially applied gate to reconcile. |
| Coordination has no private channel | The product ships no agent-to-agent messaging. Agents coordinate through recorded surfaces only, so "who told whom what, and when" is a query against the record rather than an interview with the people involved. |
| A control that cannot be enforced stops the work | A missing confinement facility, an unreadable policy value, an unadmitted machine or an ambiguous target are refusals with named reasons. The product does not fall back to a weaker posture and carry on. |
Three kinds of record, three different strengths
This is the distinction to take into an audit, because the three are routinely treated as one thing and they are not equally strong. Asking the wrong one of them for the wrong kind of assurance is the most common way to overstate this trail.
| Kind of record | What it will support, and what it will not |
|---|---|
| The governance record — who was admitted to the fleet, by whom, when, and with what authority | Non-repudiation. A third party holding only your root public key can verify the whole governance history, without trusting the machine that produced it. This is the strongest of the three. |
| Gate decisions — the actor, the decision, the time, and the evidence the decision rested on | Tamper evidence. A later edit of any field, including the actor, breaks verification, and verification is re-checked at merge rather than only when the row is written. It does not establish which holder of the workspace key wrote the row. If your question is which individual decided, this record narrows it to the key and to the name recorded, and it does not go further than that. |
| Run records — what ran, under which configuration and which standing instructions, at what cost, in how long, and on a refusal the rule and the reason | Content provenance. These are not signed. They pin content and identity, which is a different and weaker claim than a signature. Read them as an account of what happened, and use the two records above where you need something a signature has to carry. |
The middle row is the one to quote in a walk-through. The distinction is drawn deliberately in the product's own security documentation, for the same reason it is drawn here — collapsing it would overstate what the trail offers.
Two things a refusal is
A refusal is not an error report. On this architecture it is a control that fired, and it is recorded with its named class and its reason at effectively no cost. That means accountability covers not only what the system did, but what it declined to do — a refusal ledger reads as the work, the money and the risk that did not leave.
It also means a rising count of one refusal class is a signal about your estate rather than about the software. Checks you can run yourself names the classes worth watching.
One qualification belongs on this page rather than in a footnote, because an auditor will test the word every. Refusals raised before a run exists — a policy document that is absent or unreadable at the moment of dispatch, for instance — end on the operator's terminal and leave no row. The ledger holds refusals of work the product started to carry out. It is not a complete log of every time the product said no. What this does not prove states the consequence.
What an auditor asks next
- Is segregation of duties enforced, or documented? The properties above establish that the engine cannot approve and that a decision out of order is refused. Whether the implementer, the reviewer and the approver of a given change were distinct people is a question you answer from the actor names on the gate rows and the review verdicts for that stream — see tracing one change backward. Read that as a property of your roster and your process, evidenced by the record, rather than as a claim this page makes for you.
- Can I see the trail without your tooling? Partly, and the honest answer is on where the evidence lives.