Review Is Not Approval
The problem, in one sentence: a clean review gets treated as permission to proceed, and afterwards nobody can say who decided.
The principle
Review answers one question: is this sound, and what is still open?
Approval answers a different one: may this proceed, and who answers for that?
They are usually answered by different people, at different moments, from different authority. A clean answer to the first is never an answer to the second.
The structure
| Review | Approval | |
|---|---|---|
| The question | Is it sound? What is still open? | May it proceed, and who answers for that? |
| Who answers | someone other than the author | someone who holds the authority for this kind of decision |
| What it leaves | findings and open questions | a recorded decision |
| What it is bound to | the exact version that was read | the exact version that was approved |
| What makes it lapse | any change to what was reviewed | any change to what was approved, or to the conditions it assumed |
The order is fixed, and each step leaves its own record:
- The work is prepared — by a person, a vendor, or AI.
- It is reviewed — findings and open questions, on one exact version.
- It is approved, or not — a decision on that same version, by whoever holds the authority.
- It is carried out — by whoever performs the change, who checks that 2 and 3 still hold and adds no judgment of their own.
- The result is read back — the state that now exists is compared with the one that was approved.
When to use it
- A reviewer's "no issues found" is being read as a go-ahead.
- AI or a vendor prepares the work, and a person is said to "check" it.
- Approvals are recorded against a document's name rather than its version.
- Nobody can say what would make an existing approval stop applying.
- The person who holds the authority is also the only one who can carry out the change.
The common failures
Review taken as approval. "It was reviewed" closes a question nobody actually asked. The reviewer answered whether it was sound; nobody answered whether it should go ahead.
Approval of a moving target. The work changes after it is approved — a fix, a late edit, a new version from the vendor — and the approval carries over silently, because it was attached to a name and not to what was read.
Authority merged into execution. The person with the authority to decide is also the one who must carry out every change, so the two get merged to save time. The decision stops being recorded separately, and the record shows only that something happened.
Implementation notes
- Keep two records, not one: the review's findings and the approval decision.
- Bind each record to the exact version it covered. A change to that version invalidates both, and the review is done again on the new one.
- When it is unclear whether an approval still applies, treat it as not approved. Fail closed.
- Let whoever holds the authority approve without having to perform the change, and let whoever performs it check the conditions mechanically rather than decide again.
- Read the result back after the change, and record that the state reached is the one that was approved.
None of this needs a new system. It can usually be done with the documents, tickets, and approval steps already in place — what changes is what each record is allowed to mean.
Related
The Practice Note AI Delegation Reveals How Work Was Designed looks at the acceptance conditions this protocol assumes already exist. Whether a workflow's AI output has defined acceptance conditions and reviewers is one of the questions the AI Operating Model Diagnostic Kit works through directly.
What Fragment Practice works on
Fragment Practice works on where review, approval, and execution sit in a real piece of work: who reviews which version, who holds the authority to let it proceed, and what makes an approval stop applying. It does not take over the approval, and it does not carry out the change.