The system hands off when it loses its grip, which is when the situation is most complex

What it is

Automation does not hand work back on easy stretches for practice. It throws the work back when it can no longer do it. Bainbridge already named the irony: what is left to the person is the residual the designer could not automate. Handoff at loss of grip is a coupling: the reason for transfer (the machine is stuck) is bound to situational difficulty (this is the messiest moment).

What the person receives is not an average task. It is the machine’s failure sample.

Why it happens

Situations on a capability boundary usually stack anomalies: a non-standard object, a tool error, part of the outside world already changed. Supervisory control gives the easy stretches to the machine; the person’s skill and situation model decay on those stretches; when the person must act, the task distribution has already shifted off the training distribution. This is not “sudden”: even with ample preview and a complete brief, the task itself is harder than the stretches the machine just finished easily. Suddenness is timing; this is a selection bias on difficulty.

If a product only calls the person on failure, it is using them as an exception processor while estimating their readiness from normal tasks.

Studying it

Compare two kinds of transfer: a random stretch handed to the person (including mid-success), versus only on system failure. Dependent variables: quality after taking over, time, subjective difficulty, whether more context is demanded. Independent variables: failure type (permission, ambiguity, partial execution), whether the person saw similar successful stretches before the failure.

A training variant lets people take over periodically on success, then measures performance on failure — a test of whether “only meeting on failure” is hurting performance when failure comes.

Where it stops holding

A system that hands back while it still has grip (adjustable levels, a practice mode) breaks the coupling on purpose. Never handing off, failing to a stop that waits for an expert, also does not throw the person into the hardest beat. Skill degradation is a long-term consequence and one cause of this selection bias, but a different mechanism. This entry does not discuss whether the transfer is sudden.

Applying it

• Do not design the person’s station only on the failure path. Schedule sample takeovers on the success path so people have seen “what normal looks like,” and have a contrast when failure comes.
• Failure handoff must be provisioned as harder than the average task: more context, a longer window, clearer acts-already-in-effect — not a reuse of the normal confirm box.
• Check: split completion time and errors for mid-success takeovers versus failure takeovers. If failure takeovers are substantially worse and the product uses the same handoff UI, average tasks are being used to estimate extreme ones. Add success-path takeovers to the daily, measure failure scores again — if they rise, practice can interrupt the coupling.

Related

• Same group: L4.04.1 Handoff needs enough time to rebuild the situation · L4.04.2 The system state at handoff must be fully briefed · L4.04.3 Sudden handoff is the most dangerous form · L4.04.4 Handoff quality depends on whether the giver explains how the situation was reached · L4.04.5 Time to rebuild the situation is a hard constraint and cannot be squeezed to zero · L4.04.7 Responsibility transfers immediately after handoff; the transfer must be confirmed by the taker, not assumed · L4.04.8 Reverse handoff needs design too; when a person hands back, they must say what they changed
• Nearby: L4.09 Skill Degradation · L4.13 Agent Failure Reporting and Escalation · L4.01 Levels of Automation
• Search terms: ironies of automation · handoff at failure · residual task