Part III · Chapter 5 · Evidence · lesson 4
The best evidence is the thing the work produces anyway
14 min
Builds on Automating it changes what you have to prove, not how much
Part III · Chapter 5 · Evidence · lesson 4
14 min
Builds on Automating it changes what you have to prove, not how much
Two companies run the same control: no change reaches production without a second person approving it.
The first company has a quarterly evidence task. Somebody opens the repository, exports a list of merges, pastes it into a spreadsheet, adds a column for the approver, and files it. It takes a morning. It is on one person's calendar, it is the first thing dropped when a release slips, and it produces an artefact about the control.
The second company has no evidence task at all. The branch cannot be merged without an approval, so every merge in the history already carries the name of the person who approved it. The evidence is the repository. Nobody collects it because there is nothing to collect.
Predict
The best evidence is the by-product of the work.
A ticket that cannot close until somebody other than the author marks it approved. A pipeline that writes its own log to somewhere durable. A review performed in a tool that stamps the date and the reviewer without being asked. A payment that will not leave without a second authorisation.
In each case the artefact exists because the work happened, not because somebody remembered to record that it happened. Doing it and evidencing it are one action.
Design for that at the start and the evidence question stops being a separate project. Design against it — a control performed in conversation, a check done by eye, an approval given verbally — and you have created a permanent collection task whose output is weaker than the one you did not build.
Not what will we write down. What will exist afterwards that we did not have to write down?
Three answers, in descending order of how much they survive:
Most registers are full of the third because that is the cheapest to set up and the most expensive to keep.
Now take one for yourself. The control below is the one where this plays out most often, because the policy and the repository settings are usually written by different people at different times and nobody compares them.
Decide · change-approval-independence
The point of an approval is that a second brain looked. Self-approval is not forbidden by arithmetic in a small team — sometimes there is genuinely nobody else awake — but it has to be a decision somebody made and can defend, rather than a gap nobody noticed between the policy and the branch protection settings.
The decision
Whether independent approval is a rule, a default with named exceptions, or honestly impossible at this headcount. All three are defensible and only one of them is true for any given company. If it is impossible, the decision is what stands in for it: a post-hoc review of merges, a pairing norm, an automated gate that cannot be bypassed by the person who wrote the change.
Where this goes wrong
The policy and the repository settings are written by different people at different times and nobody compares them. The policy says two approvals; the settings allow an administrator to merge alone; both are true, and the only artefact that shows the gap is the merge history, which is also the one nobody exports until an auditor asks.
Does this apply to you?
What does not line up
Nothing yet, because there is nothing in here yet. An empty workspace has no contradictions and tells you nothing.
These are contradictions between things you wrote. Nothing here can tell you whether any of it is enough — that is a judgement, and it moves with the auditor, the boundary and the year.
Three outcomes are interesting here.
If you marked it running and nothing is attached, the engine says so and asks what you would hand someone who asked to see it running. In this particular case there is usually an answer sitting in the repository that nobody thought to call evidence, which is the most common pleasant surprise in this track.
If you recorded that independent approval is honestly impossible at your headcount, that is a legitimate decision and the engine does not argue with it. What it does require, through the justification, is the sentence you would say out loud — and the useful version of that sentence names what stands in: a post-hoc review of merges, a pairing norm, a gate the author cannot bypass. Each of those also produces its own by-product, which is the point.
If you named an owner who is also the person who performs the control, nothing fires, and it is worth sitting with anyway. Failure and detection then share a single person, and the evidence of both is the same artefact.
There is one way this design goes wrong, and it is not about the control.
The by-product is perfect and it lives in a tool that cannot be shown to anybody outside the company. A ticketing system holding customer names in the same records. A repository whose history cannot be shared because the code is in it. A chat workspace where the approval sits in a thread with four unrelated conversations.
The control is strong, the artefact is strong, and producing it for somebody else means an export that strips things, or read-only access nobody can authorise, or a screen share. None of those is impossible and all of them are work you did not plan for.
Worth asking at design time, in one sentence: if somebody outside needed to see this, what would they look at and who would have to approve that? It is a cheaper question now than in the fourth week of fieldwork.
Check