Approval — Who Accepts This?

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.