Skip to content

Approval · the five-minute version

Approval in five minutes

Nothing here is a summary written after the fact. These are the problem, mechanism, and move of each article, in the reading order, joined by its own connective lines. Any one of them opens into the full argument.

Start with where an approval has to sit in order to be one, which turns out to be inside the change it approves and nowhere else at all.

Justification travels in the diff

Problem
Rules, rulings, and approvals are naturally filed where rules live, in a policy file or a decision log, while the reviewer who has to act on them is reading a bounded set of added and removed lines and nothing else.
Mechanism
A justification held anywhere except inside the change is absent at the instant the decision is made, which is why the oldest working version of this rule puts the certification in the commit rather than in a register.
Move
Put the reason where the change is. If a rule governs an edit, it belongs in the same diff as the edit, and a system that cannot arrange that has separated its reasons from its decisions on purpose.

Some approvals are standing rather than single, and the honest form of a standing exception is a list that is only ever allowed to get shorter.

The ratchet

Problem
A standard a codebase does not yet meet has two usual fates. Enforce it and the build goes red on work nobody has time to finish, so the check is switched off within the week; write it down as an aspiration and it never binds anything.
Mechanism
The exception is enumerated rather than general, so the check stays green on the exact breaches somebody has already looked at and red on every new one, which makes the standard binding from today without requiring the past to be paid off first.
Move
List the known breaches with a reason attached to each, refuse blanket patterns outright, and write into the list itself that it may only ever get shorter.

Move from an exception a reviewer grants to a permission a person gave, and put it somewhere the build refuses to compile without it.

Consent that fails CI

Problem
Consent in most software is a record of what the user agreed to, consulted at runtime by guards that fail the way all runtime guards fail, silently and after the flow already happened.
Mechanism
A type system can make an illegal state unrepresentable, converting a class of runtime failures into build failures; consent typed onto the data travels with it, and a policy permitting an illegal flow stops compiling.
Move
Encode consent as a property of each piece of data, checked in continuous integration, so a violating change is rejected before it ships rather than detected after it leaks.

Then the approvals that cannot be withdrawn once given, which the cleanest systems record as permanent rather than promise to reverse later.

Disclosure is irrevocable

Problem
Systems that move material across a read boundary want to describe the move as reversible, because deletion is the remedy everyone knows how to build and the one every person asks for.
Mechanism
The event is typed as durable and non-revocable in the format itself, so a record describing a disclosure as undoable is not a rejected record, it is not a record of this kind at all.
Move
Type disclosure as permanent and spend the recording budget on who, what, from where, and to where, because attribution is the only remedy that was ever actually available.

End on the one thing that genuinely can be taken back, and on the precise reason it can, which is that erasure has something to destroy and a reading does not.

Destroy the key

Problem
A system that must prove what it did keeps an append-only history, and a person described inside that history has a legal right to have their part erased, so the ledger and the right appear to rule each other out.
Mechanism
Erasure operates on the key rather than on the history, so destroying the key leaves the sequence, the hashes, and the replayability intact while the personal content inside becomes unrecoverable.
Move
Hold personal content under a per-person key stored somewhere else, and state the caveat as loudly as the capability, because the guarantee is exactly as strong as the key management underneath it.

You have walked The approval that travels end to end: where a reason has to sit, how a standing exception stays honest, what a permission looks like when the build enforces it, which decisions are permanent on arrival, and what remains recoverable after all. None of these turned on anyone being more careful. Every one turned on whether the record could express the thing a careful person would want to say.