Approval — Who Accepts This?
The third discipline: which outputs may be applied automatically, which need one reviewer, and which need two. Five chapters.
4. Authority is designed before it fails
Decide what a role may veto before you find out how it fails.
Two roles in the same operation made errors of comparable magnitude. One held a veto; one did not.
The role with veto authority raised a false alarm, and it was expensive. The role without raised a larger error, and it cost nothing — because nothing downstream depended on its judgment.
The difference was not competence. It was authority granted in advance.
This is the design question most approval architectures never ask. Not who is good at reviewing, but what happens when this reviewer is wrong — and it has to be answered before they are wrong, because afterward it becomes a negotiation.
The loop
Approval is not a checkpoint. It is one stage in a cycle that must close.
Propose → Review → Apply → Record → Synchronize
| Stage | What it does |
|---|---|
| Propose | The AI produces work |
| Review | Judged against a standard — or against plausibility |
| Apply | The accepted change reaches the real system |
| Record | Who approved what, against which version — this is where Approval hands to Warrant |
| Synchronize | Downstream systems reflect the change, or drift begins |
A loop that does not record is not a loop. It is a sequence of decisions that cannot be reconstructed — so the next reviewer starts from nothing, and the same question gets re-decided.