Putting a person in the loop also puts liability on them; that transfer must be said, not assumed

What it is

Organisations often embed a person in the loop so that after an incident there is a signature. At the moment of embedding, liability moves from the system side onto the person who signs — that is how the institution runs, and the interface almost never says so. The transfer must be explicit: people have a right to know which stretch of consequence they are taking, and a right to refuse the take when conditions are short.

An implied transfer treats attribution as unread terms.

Why it happens

Approve in everyday UI feels like Continue. Continue does not move liability; Approve will, in an incident review. Two speech acts share one button. People press continue and are written down as having approved. Afterwards they report “I thought I was just letting it go on”; the review writes “confirmed by a human.” The mismatch is not them dodging. The control stacked the two acts.

The card on nominal loops treats whether causality is wired. Here, even when it is, attribution semantics may still have been smuggled. Without an explicit statement, people cannot protect themselves with “conditions short, I refuse,” and they still press when materials are thin — because it looks like progress, not a legal act.

Studying it

An incident script: a harmful act released through the gate. Ask the person who released “who is responsible,” and look at the approve label, the confirm copy, whether a right to refuse is recorded. Independent variables: the button says Continue versus I confirm and accept responsibility for this act, refuse as usable as approve. Dependent variables: attribution, use of refuse, whether they still release when materials are short.

Self-report of “I knew I was responsible” must be measured apart from how the label was understood. Many will agree to responsibility afterwards and were understanding Continue at the time.

Where it stops holding

An advisory system that does not claim a transfer, if the organisation still pins “someone glanced” after an incident, is scapegoating outside the loop — not an interface this card can fix — but the UI should not offer that glance as a fake node. An employed reviewer’s contract may already name liability; the UI still has to name this instance’s objects, or the contract is general and the act is particular. This entry does not site the gate.

Applying it

• The primary on an irreversible gate is Confirm and send / I accept responsibility for this operation, not Continue or Next. Refuse sits beside confirm, not as a corner Cancel.
• The release record states who, under which materials, on which objects. When materials are short the person should be able to tick “materials insufficient, refused.”
• Inward and outward copy agree: if the outside is told a person is in the loop, the inward handoff must show the scope of liability where the person coming on shift can see it.
• Check: walk a gate and ask “if you press, and it goes wrong, whose is it.” “Don’t know” or “the system’s,” while your incident process will look for this person, means the transfer is implied. Then see whether refuse is as easy to press as confirm.

Related

• Same group: L1.09.1 Where to put the intervention is decided by reversibility · L1.09.2 Intervenors need the context that reconstructs current state · L1.09.3 Too-frequent intervention turns review into a rubber stamp · L1.09.4 The higher the system’s accuracy, the worse actual supervision
• Nearby: L1.05 Human in the loop · L4.15 Accountability and traceability · L4.04 Takeover and handoff design
• Search terms: liability transfer · approve versus continue · explicit responsibility at the gate