Tracing one change backward
The walk-through — from a merged change back to the decision, the review, the order and the cost.
This is the walk-through to run in the room. Pick one merged change, ideally one the operator did not choose for you, and follow it backward. Every link in the chain is a record that existed before your question was asked, which is the property being demonstrated — not the neatness of the chain.
Work backward rather than forward. Forward from an order you are shown what somebody intended; backward from a merge you are shown what actually landed.
Each command below takes the workspace it should read. Substitute your own path for <path>.
Start at the merge, in your own version control
Take the merge commit from your own repository, not from us. The product observes commits, branches and change requests and never writes to them, so your version control is the independent end of the chain — the one link whose integrity does not depend on anything the product did.
Note the commit identifier. Everything below hangs off it.
What an auditor asks here — could the product have created this merge? No. A merged state is observed from a real merge and is never a status the engine grants. If a change is in your main line, a human or your own automation put it there.
Find the decision that authorised it
Each row is one decision, and carries the actor, the decision from a closed set of words, the time, and the evidence the decision rested on. Locate the row for this change's stream.
Read the actor name as a registry handle, not as a free-text field. Where a historical spelling appears, the render shows it verbatim with a marker indicating the canonical actor it resolves to.
What an auditor asks here — three things, and they are the substance of the walk-through:
- Was there evidence, or just an approval? An approval without evidence attached is not representable. If the decision exists, evidence was supplied for it.
- Could the row have been edited since? A later edit of any field, including the actor, breaks verification — and verification is re-checked at merge rather than only at the moment of writing. So an edit made after the fact would have had to survive a check performed at the merge you started from.
- Does it establish an individual? Not on its own. It establishes the recorded name and that the row verifies under the workspace key. It does not establish which holder of that key wrote it. Take that limit seriously and read what this does not prove before you write the finding up either way.
Where a review verdict fits. If your process requires a change to be reviewed before it is approved, that verdict reaches the auditor as part of the evidence the gate decision rested on — the same field you read above. This section does not document a separate review-verdict surface with its own guarantees, so ask your operator which artefact in the evidence for this stream is the review, and cite that artefact rather than a step in a diagram.
Confirm the deciding name was allowed to decide
The name recorded as having decided must be enrolled and active in the signed actor registry at the moment of the write, or the write is refused. That check has no off switch, no warning tier and no grace period.
This command reports the roster gap — every actor name the gate log records, how many rows each has written, when each was last seen, and what the guard would say about it today. Read the status word before the rows. A gap that could not be measured is reported as unmeasured, and nothing about who would be refused may be concluded from it.
Add --json for a machine-readable report if you are collecting this into working papers.
What an auditor asks here — can a retired name still approve things? No. Retiring an actor takes effect immediately, regardless of any grant that has not expired. What survives is the decisions that name already wrote, which keep their verification either way.
Read the order that commissioned the work
Work is commissioned by a document, and the document is addressable. Signing it proves who wrote those bytes; registering it answers the other question — is this the current order, and which exact bytes were they? — by recording the document's digest, the commit that carries it, who signed it, and until when it stands. What comes back is a short reference you can paste in place of the document's body.
The check resolves the reference to a registration and confirms that the committed bytes match. Passing the document's path instead does not weaken it — the path must still resolve to an active registration over matching committed bytes.
A registration's currency is one of a closed set of words, and it is computed from an append-only log of acts rather than stored as a field anything can overwrite. Withdrawal is a new act. That is why the record can still answer the question an auditor actually asks: what did this order say at the moment that run was dispatched — not what the file says today.
What an auditor asks here — was the work in scope of what was authorised? Compare the registered order at dispatch time against the change you started from. This is the step where a scope finding surfaces, and it is the reason a reference is worth more than a link to a file.
Read the run that did the work
The run record states what ran, under which configuration and which standing instructions, what confined it and which directories stayed writable, how long it took, what it cost, and — on a refusal — the rule and the reason. Read it as the account of what happened, as distinct from what was requested.
Two properties of this row matter to a walk-through. The confinement claim it carries is reproducible: it names the enforcing tool and the writable directories, so your own team can run the same tool with the same policy and attempt to write outside them. And the binary's identity was resolved on the machine that ran it, not on the control plane that dispatched it.
Run records are not signed. They pin content and identity, which is a weaker claim than a signature — see what the record guarantees for why the three kinds of record are kept apart.
One honest note on the surface. This section does not document a single command that prints a run record for you, and it will not invent one. The rows are in your record store and are queryable there; the surfaces that render them belong to operations. If your walk-through has to be repeatable by a non-engineer, agree the query or the surface with your operator before the audit rather than during it.
Read what it cost, in the same place
Cost sits on the run's own row, next to the evidence for the same work rather than on a separate invoice, and it is recorded as names, references and numbers only. What did this change cost therefore gets its answer in the same record, and from the same walk, as who approved it. That is the difference between a governed process and two systems that happen to be about the same work.
One cost fact is worth an auditor's attention in its own right, because it is a fail-closed default rather than a feature. A seat can carry a billing class, and the class lives on the same signed seat row as every other fact about that seat — changing it means a new owner-signed entry, not a configuration edit, so nothing can move a seat onto pay-per-token billing without an owner deciding so on the record. An absent class is projected as unknown, never as permission. A consumer that gates spending on an explicit class therefore treats every seat that predates the field exactly as it treats an explicitly metered one — refused until an owner act says otherwise. A permissive default here would have made the guard decorative on every seat that already existed.
machine list and fleet show both project the current billing class beside the rest of a seat's identity, so you can check it without a separate query.
What an auditor asks here, and this section will not answer for you — whether a per-run budget was set and enforced before dispatch. The cost recorded on the run row is what happened; the controls around a quote, a ceiling and a capacity check before a run starts are not documented in what this section holds. Ask for them by name and expect to be shown the operations material rather than this page.
State the chain, and then state its ends
At the end you should be able to write one paragraph — this merge, that decision by that actor with that evidence at that time, commissioned by that order in those exact bytes, executed by that run under that configuration at that cost. And you should be able to say which links you verified yourself and which you read.
Those are different, and checks you can run yourself is the list of the ones you can move from the second column to the first.