Human judgment remains part of the system

On the architecture diagram, the purchase step is a stick figure standing beside the flow with the caption "user approves". Ask what the user sees at that moment, how long they have, what the run does if they never respond, or who is answerable when the wrong order goes out, and the room has no answers. The step is on the diagram. It is not in the architecture.

Two quarters later a backlog item reads "remove manual approval", and there is nothing to argue with, because the step never declared what it was for. White Paper Principle 10 is usually read as a reassurance that people still matter. It is better read as a placement requirement: human involvement has to be located in the specification with the same declared inputs, outputs, owner, and timing a cognitive unit gets, because an unspecified human step cannot be defended, measured, or correctly removed.

Helpful context: Human judgment that should remain argues why particular decisions belong to people, which this page assumes rather than repeats. Judgment should be explicit and judgment should have locality are the two principles this one extends to human steps.

A human step needs an address

Principle 1 requires every open judgment to be nameable, and Principle 2 requires it to have one primary home, which may be deterministic code, a cognitive unit, an agent strategy, or a person. A human step is one of those four homes rather than an exception to the scheme, so it inherits both requirements. Judgment should be explicit and judgment should have locality own those rules, and Principle 10 is what they amount to once applied to the fourth home.

An address means four things the specification can be read for: what the step receives, what it returns, who owns it, and what happens when it does not answer in time. "User will approve" supplies none of them, and the omission is not cosmetic. Duplicate human paths then produce the defects that duplicate cognitive units produce, so if the mobile flow requires approval above one threshold and the web flow above another, a single consent decision has two owners and nobody can say which one is the policy.

In the Meal Companion the purchase approval node sits inside the chain rather than beside it. Shopping-list assembly runs in deterministic code, the approval node takes the assembled list and returns a decision, and idempotent order placement runs in code again. Drawn that way it has the same standing as ComposeWeek or the allergy gate, which is the whole point: a human step is a link, not an interruption of the flow.

ComposeWeek proposes planHousehold acceptsCode assembles listHuman approves purchaseDeterministic order

Each human node has declared inputs, a scope, and a return path.

Six places people belong, and they are not interchangeable

Principle 10 does not ask for a human in the loop. It names six locations the specification has to settle: where people approve, where they intervene in a run, where they supply context the system does not hold, where they resolve disagreement, where they calibrate evaluation, and where final responsibility rests. Collapsing them into one node is how the phrase "human oversight" comes to mean nothing in particular.

They have to stay separate because they behave differently over time. An approval gate does not move when confidence rises, since it exists for consequence rather than for uncertainty. A context handoff should become rarer as knowledge coverage improves, because its cause is a gap that can be closed. Calibration moves the other way and matters more as scores improve, since somebody has to keep deciding whether the grader still agrees with domain judgment, which evaluation is part of architecture develops.

The practical consequence is that "remove the human" is not yet a proposal. It becomes one when it names which location and what changed. The Meal Companion has people in four of the six: the household supplies context when leftover acceptance is unknown, resolves disagreement when two members want different weeks, approves the purchase, and holds responsibility for the dietary restriction list. Four nodes with four different removal arguments, all of them hidden behind one word on a diagram.

A gap you can bridge is not a boundary you cannot cross

Two of those six get confused constantly, and the confusion is expensive. When AskTargetedQuestion returns leadership because leftover acceptance is unknown, that is a cognitive unit reporting an unresolved gap in its result and naming what would close it. The gap has an answer, the answer is obtainable from a person, and the loop resumes once it arrives. When the system should refuse covers that result shape.

Purchase approval is a different kind of thing wearing similar clothes. No retrieval closes it and no confidence threshold closes it, because what is absent is permission rather than information. That difference decides where each one lives, since a gap belongs in the result a cognitive unit returns and a boundary belongs in the architecture as a node.

Conflating them produces two symmetric mistakes, which is why the distinction earns its own section. Teams delete approval nodes on the grounds that the model is confident now, treating a boundary as though it were a gap that capability closed. The same teams tolerate cognitive units that almost never abstain, on the grounds that a person sits at the end of the chain anyway, treating a gap as though somebody else's node already covered it. Both moves look like progress on a roadmap and neither one addresses what was actually wrong. The model is not the system is the framing error underneath both.

Human involvement should be deliberately located rather than treated as evidence that automation has failed.

Thoughtware White Paper · Pr. 10

What the handoff contract has to carry

A named node is still not a working one, because what the person can do is decided entirely by what the node hands them. Artifacts come first, which for a purchase means the plan version, the material assumptions, the cost, and the flagged risks, because a summary with a button attached does not make a decision possible. Scope comes next, since approve, reject, request revision, and escalate are four different returns and the loop has to know which of them it may receive.

The remaining two elements exist for what happens away from the happy path. A time bound settles what the run does when nobody answers, which is otherwise settled by whichever timeout the infrastructure happens to have. A record settles whether the decision can be reviewed later, which is why an approval with no plan version attached is an incomplete artifact rather than a logging gap. Both are cheap to declare in advance and close to impossible to reconstruct after an incident.

A node also needs a declared way back into the loop, and the absence of one is what produces agents that repeat blocked actions or talk past the person. After a rejected purchase the agent might replan, patch one meal, or ask a targeted question, and which of those it may do is a specification decision rather than a runtime accident, which is the argument stop conditions as design makes for the loop generally. After a medical deferral the working state freezes at a checkpoint until human input arrives, so the run waits instead of being abandoned and rebuilt.

Assembled, one purchase runs like this. The household accepts a plan that passed CritiquePlan and the deterministic allergy check. Shopping-list assembly runs in code. The approval node presents items, prices, substitutions since last week, and allergy flags, with the four possible returns visible and a stated rule for an unanswered week. The approval is recorded against the plan version, and deterministic adapters place the order idempotently with audit metadata, which is deterministic code doing what only it should do. At no point does a high confidence score spend money, because capability improved the plan while authority still stops at proposal.

A node nobody funds gets deleted

A fully specified node still has an operating cost, and that cost is where Principle 10 is usually lost rather than in any argument about legitimacy. Human-led purchase approval means coverage hours, a rule for stalled approvals, and a measurement of how long they stall. Without those, the node becomes a queue, and the queue becomes the strongest available argument for removing it, which is how a designed boundary gets retired as a latency problem.

Capacity constrains the design in the other direction as well. An organisation cannot place a person behind every consequential decision and then send that person a volume of opaque approvals, because the review that results is ceremonial whatever the org chart says. Where close review is genuinely required, the automation's job becomes reducing case volume, prioritising exceptions, and preparing evidence so that the reviewer's attention reaches the cases needing judgment. Review capacity is therefore an input to the architecture rather than a staffing detail discovered after launch.

What makes the arrangement answerable is that human nodes sit inside engineering discipline rather than alongside it. Whether an approval screen reduces post-approval corrections is measurable. So is whether returns fire on the right terrain instead of firing on uncertainty alone, which trains people to ignore them. Those measurements belong in the same suite as the cognitive units, and once they exist, the question of whether a node earns its operating cost has an answer that is not a matter of preference.

What to do next

Any proposal to remove a human step should have to answer two questions: which of the six locations it occupied, and what changed. A defensible removal names the change on the record, which usually means the terrain became established, the standard held under evaluation, and a grant was issued to a named owner. Maturity moves settled work out of runtime is that path done properly.

The other available answer is that the screen was slow. A node removed for that reason was never architecture, and the decision it held does not leave with it, because it relocates into a default, a threshold, or a prompt where nobody can find it again. Human judgment that should remain is where to go for which decisions belong to people in the first place.

Read next: Evaluation is part of architecture.