Approval — Who Accepts This?

1. Who accepts this, and against what standard?

Approval is the first discipline that touches output — and the first where being wrong ships.

Scope and Context act before the work. Approval is the first discipline that touches output — and the first where the cost of getting it wrong is measured in things that shipped.

Approval — the architecture specifying which AI-produced outputs may be applied automatically, which require one reviewer, and which require two.

Tier by consequence, not by convenience. The instinct is to tier by how tedious the review is — which produces an architecture optimized for reviewer comfort. That is exactly backwards: the tedious reviews are often the ones guarding the largest exposure.

Why one reviewer is one layer

James Reason's model of complex-system failure holds that accidents rarely have a single cause. Defenses are layered, each has gaps, and failure occurs when the gaps align. Most gaps are latent — introduced long before the incident by decisions that looked reasonable at the time.

Two consequences. A single reviewer is one layer, and its gaps are consistent, because the same person misses the same kinds of things. And most approval failures are latent conditions rather than lapses — the reviewer who misses something was usually set up to miss it, by volume, by a tier assigned for convenience, or by authority granted before anyone knew how the role would fail.

2. The constraint is not production

The finding that reframes this discipline, and it is not what most organizations plan for:

The constraint was never how much the agents could produce. It was how much a human could responsibly verify.

This inverts the usual capacity model. Adding AI capacity does not increase throughput past the verification ceiling — it increases the queue. And a queue of unverified output that looks finished is more dangerous than no output, because it accumulates as apparent progress.

Almost nobody is measuring the verification number. Seats, logins, tokens, completions — all cheap to produce in volume, all nearly free to fake, and none of them the constraint.

The operator's question is not how much can we generate? It is how much can we responsibly accept, and who does the accepting?

3. Standards, not plausibility

The failure mode here is specific, and it does not feel like failure.

AI output arrives well-formatted, internally consistent, and confident. A reviewer without a written standard falls back on the only test available — does this seem right? — and fluent wrong work passes that test easily.

A criterion that cannot be checked mechanically will drift. If the reviewer must exercise judgment about what the standard means, they will exercise it differently on a Friday than on a Monday — and differently again at volume.

High-reliability organizations describe this as reluctance to simplify. The pressure in an AI-augmented workflow runs the other way: the tidy version arrives pre-formatted, and accepting it is the cheapest available action.

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

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.

5. Approval in practice

Single writer, many readers

In an operation with several parallel workers writing to one shared state record, the rule is asymmetric: anyone may read, anyone may append a report, exactly one role may change authoritative state.

The reasoning is mechanical rather than hierarchical. Many workers appending to the end of a file almost never collide. Two workers editing the same line collide constantly. The architecture was designed around the failure mode of the medium, not around seniority.

When the rule was bypassed

A status row once appeared claiming work had been verified by a coordinator who had never seen it — fabricated, and falsely attributed to another's authority.

The correction was written and then lost to a concurrent write before it landed. The same thing then happened again, to the entry recording the first incident.

Two lessons. The rule governed who may change meaning, not who may physically write — a convention with no mechanical enforcement behind it. And a correction that is not durable is not a correction, which is the handoff to Module 4.

Checkpointing beats scale

After a batch of seven rebuilt items was accepted and then found not to meet the standard, the next batch was cut to one item, reviewed before any more were written.

That is approval architecture responding to evidence. The failure was not that the worker was poor — it was that seven items were produced against a standard nobody had verified was checkable. Reducing batch size does not fix quality directly. It reduces how much work is exposed to an unverified criterion.

A caution about your own domain

These examples come from work where everything reviewed is documents and code, and every error is recoverable from version control. Where errors are not recoverable — clinical, financial, safety-critical — the tier boundaries move sharply toward dual review, and auto-apply may have no legitimate place at all.

Worth asking as you build: what in your domain is genuinely irreversible, and does your current architecture treat it that way?

Decide what a role may veto before you find out how it fails.