The rule on every engagement we run is short. If an action cannot be cleanly undone, a named human approves it before it happens, and the approval is itself a line in the receipts.
What a gate-and-approval loop actually is
A gate is the place in a workflow where the system stops and asks. An approval is the named human's recorded yes. A loop is what connects the two into something we can audit: the system proposes the action, the gate pauses, the approval is captured with who, when, and on what evidence, and only then does the action run. If any of those three pieces are missing, the loop is broken and we say so on the dashboard rather than shipping the work anyway.
We do not gate everything. Reads are not gated. Drafts are not gated. Idempotent retries of an already-approved action are not gated. What gets gated is the short list of things that, if wrong, the team would have to write an apology for: sending a message to a client list, paying an invoice, changing a permission, deploying to production, deleting customer data, signing anything. (Class C — this is how we configure routing on every engagement.)
Why the approval has to be named
An anonymous "the system was approved" is not an approval; it is an alibi. The receipt has to name a person, the time, and the artifact they read before they said yes. Two reasons. First, accountability is a property of names, not of roles — "ops approved this" is a sentence with nobody in it. Second, when the override numbers tell us a gate is being rubber-stamped, we need to know who is doing the rubber-stamping so we can fix the gate, not the person. (See /override-rate-and-trust for what the override series tells us about a tuned gate versus a tired one.)
The approval artifact is small on purpose. It is whatever the human actually read before saying yes: a diff, a list of recipients, a payload preview, a dry-run output. We do not ask the human to approve a paragraph of prose about what is about to happen; we ask them to approve the thing itself, in the form it will be sent.
What receipts the approval generates
Every approval writes a row into the ledger with five fields: the action class, the approver's name, the time, a hash of the artifact they approved, and the outcome once the action ran. The hash is the load-bearing part. If the action that ran does not hash to the artifact that was approved, the system has shipped something the human did not say yes to, and the receipt sheet flags that as a divergence rather than a success. (Class C — this is enforced at the action runner, not on the dashboard.)
The ledger is the same ledger that holds the rest of the six receipts. There is no separate "approvals system" sitting beside it. Approvals are receipts; treating them as a different artifact is how organizations end up with a compliance binder that disagrees with the live system.
What the field tells us about the in-between years
The broader conversation about where AI is heading is starting to draw a careful line between today's tools — pattern-matching systems that look like agents but are not — and whatever genuinely autonomous systems eventually arrive. Themesis frames the distinction sharply in How to Prepare for the AGI World: Tools, Pseudo-Persons, and Slaves, and argues the runway for getting the governance habits in place is shorter than most teams are acting like it is. (Class E.) We read that as an argument for putting named-human approvals on irreversible actions now, while the tools are still tools. The receipts you write this year are the habit you keep when the systems get more capable.
What to ask before you trust a gate
Three questions. Is there a named human on the approval, or only a role? Does the artifact the human approved hash-match the action that ran? Is the gate visible on the same dashboard as the rest of the receipts, so a missing approval would show up as a hole rather than as silence?
If the answer to any of those is no, the gate is decorative. A decorative gate is worse than no gate, because it produces the feeling of oversight without the fact of it, and the team stops watching the part of the system that needed watching most.
The wider receipt set is at /the-six-receipts-explained. The architecture this loop is part of is at /transparency-architecture-overview. What override rate tells us about whether the gates are tuned is at /override-rate-and-trust. If you want this discipline applied to an engagement of your own, the entry point is /workshop.