What the record guarantees
The properties that hold by construction, and the four kinds of record that carry four 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. It lands a change on your main line — and, with a forge credential configured, pushes it and calls the forge's merge — only as the consequence of a recorded owner decision, 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 reads the merged state from your own version control. A merged state in the record therefore has a commit behind it. The engine's own merge commits carry text trailers naming the decision; they are not cryptographically signed. |
| 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. |
Four kinds of record, four different strengths
This is the distinction to take into an audit, because the four 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, in the sense that a third party holding only your root public key can verify the whole governance history offline, without trusting the machine that produced it. |
| Gate decisions — the actor, the decision, the time, the evidence the decision rested on, the signing key and the checkpoint | Two regimes, and the row says which it is in — saphan gates prints each row's regime. Above the person epoch an owner-class gate (stop1, stop2, merge, promotion) is signed by the person's own key — Touch ID in the console, or a security key at a terminal — and the row names that pck-… key (person-v2); master- and review-class gates are signed by the seat that decided (seat-v2). A workspace-key row for an owner-class gate is refused there, and the assertion is kept. Until the owner declares the epoch, and for every row at or below its boundary, the row is signed by the workspace key (workspace-mac): tamper evidence, which does not establish which holder of that key wrote it and which a third party cannot verify. Those rows stay as they are; none is re-signed. Item "the person decided" therefore holds only for gates above the epoch. |
| Coordination documents — the work order, the executor's status report, the review order, the review verdict and the review notes | Kept in full, and signed by their author. Each one is stored as its exact full text and signed when it is written: the order by the person who issued it, the status report by the agent seat that did the work, the review verdict and notes by the reviewer's seat. A third party holding your root public key checks the signatures offline with saphan-verify, as of a checkpoint and within the limits on the limits of the signed record. ⚠ That verifier and the export it reads are not yet shipped as release commands — see verify a change yourself. |
| 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 governance record and the gate decisions where you need something a signature has to carry. |
The gate-decision row is the one to quote in a walk-through, and the first thing to establish about it is which side of the person epoch it is on. The distinction is drawn the same way in the security documentation, for the same reason — collapsing it would overstate what the trail offers.
The five things a third party can now check about one change, and the conditions on each, are stated together on what a third party can check; how to run the check is on verify a change yourself. "Non-repudiable" is used on this site only with that offline check beside it.
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.