If nobody can name the reviewer, there is no loop.

A human in the loop is a person who inspects the output before it has a consequence, and who can stop it. Both halves matter: the inspection, and the authority.

Without the authority, the review is advisory. Advisory review produces the same defects as no review, at a higher cost, because the organisation believes it is covered.

Without the inspection, the authority is a signature. A person approving four hundred items an hour is not inspecting anything, and the numbers on the page will show it later.

So the design question is not whether a human is involved. It is at which decision, with what information, and with how much time.

Before publishing: a reviewer approves each item. The most expensive and the strongest, appropriate where an error cannot be corrected afterwards, such as a medical claim or a legal notice.

During exceptions: the system publishes automatically unless a condition fires, and the condition routes the item to a person. Cheap and scalable, and only as good as the conditions, which are often written from the same assumptions that produced the errors.

After the fact: a sample is audited on a schedule, and findings feed back into the prompt, the template or the process. Good for high volume and low consequence, useless if the sample is chosen by the team being audited.

Most real systems combine all three: sampling everywhere, exceptions for risk, and per-item review only for the smallest set of cases that are expensive to get wrong.

The failure mode is recognisable. The queue is longer than the day. The reviewer checks the first item carefully, then the first line of the rest. Approval becomes the default and rejection requires effort.

It is worse when approval is measured. If a dashboard tracks items processed, the reviewer is rewarded for speed, and the fastest way to process an item is to pass it.

It is worse again when the reviewer has no way to check. A person asked to certify accuracy with no access to sources, no time to search and no subject training is making a guess and signing it.

None of these is a person failing. They are a process designed so that the cheapest action is the wrong one, and the same design produces the same outcome in every team that adopts it.

Five conditions. If any one is missing, the review is decorative, and the other four do not compensate.

Process documents and policies written by a model are full of actions with nobody behind them: it is recommended that drafts be reviewed, the content should be checked, best practice is that stakeholders sign off.

Each sentence sounds like a control and specifies nothing. No role, no moment, no consequence, so each can be satisfied by anyone or by no one.

The correction is mechanical: replace the passive with a role and a moment. The commissioning editor checks the sources before the draft moves to design, and can send it back.

Do this to the review policy before applying it to the work. A policy that cannot name its actors will not be followed, because there is nothing to follow.

Reviewing everything equally produces rubber-stamping. Rank by consequence: what happens if this sentence is wrong, and to whom.

For each content type, three or four checkable things are enough. For a product page: price, availability, compatibility and the returns window. For a technical guide: commands that run, versions that exist, and a step a beginner can follow.

Style is the least valuable thing to review and the easiest to measure, which is why it dominates review checklists. Remove it from the human step and handle it with a linter, a template or nothing at all.

The test of a good review list is that a reviewer can complete it in the time allowed and be confident about each answer. Ten items nobody can verify is worse than three items anybody can.

Some items should not go to the general reviewer. Define the triggers explicitly: anything numerical that a customer will rely on, anything referring to law or health, anything about money, anything a regulator might read.

Escalation needs a destination and a time bound, or it becomes a queue nobody owns. A named specialist, a stated response window, and a rule for what happens when the window passes.

The rule should default to not publishing. An item that misses its escalation window and publishes anyway teaches everyone that escalation is optional.

Keep the triggers short. Five specific conditions that fire are worth more than a principle that fires never.

A decision record per reviewed item costs seconds and answers every later question: who approved, when, what they altered, what they were shown.

It also changes behaviour. A reviewer who knows the record is visible reads the item rather than the title, and a process owner who knows the record exists stops assuming the step happens.

Keep the record even when the item was approved unchanged. The absences are the useful part: a set of items approved in four seconds each is evidence about the process, not about the content.

Retention is a policy question, and the safe default is long enough to cover the consequence. If a page stays published for three years, its review record should too.

Rejection rate: if it is near zero, the reviewer is not reviewing, or the filters are so good that the loop is unnecessary. Either finding is useful.

Time per item, measured rather than expected. It tells you whether the allowance matches the task, and it is the first number to look at when quality falls.

Defect escape rate: errors found after publication, divided by items published. This is the only metric that measures the loop rather than the activity.

Override rate, for exception-based loops: how often the reviewer reverses an automated decision. A rate of zero means the conditions are wrong or the reviewer is not looking.

Put one human gate at the point of highest consequence, with the time and the evidence to use it, and automate everything before and after.

Then widen only where the escape rate justifies it. Every gate has a cost in delay and attention, and a process with nine gates has a reviewer who skims all nine.

Write it down in one page, with roles named rather than departments, and test it by trying to reject something. If rejection is easy, the loop works. If it is awkward, you have found the thing to fix.

The point of the loop is not that a human touched it. It is that a specific person could have stopped it, and did not.