Reverse handoff needs design too; when a person hands back, they must say what they changed

What it is

The person takes control, deals with it, and has to give it back. Reverse handoff does not end on a “continue” press. When the system runs on, it must know which objects the person changed, which constraint is void, which step must not be done again. Reverse handoff must declare human changes treats the person as the giver, with the symmetric duty the system has when it hands over: say what you touched.

If a person quietly changes the recipient and hits continue, and the system sends on the old plan, the system is not being disobedient. The handback protocol is empty.

Why it happens

Automation does not automatically acquire the person’s intent during takeover. If all it sees is “control is back,” it will continue from its last plan or from stale state. Some of the person’s changes are on the UI (a field edit); some live only in a decision (skip this step, void that mail). If the latter are not said, the system cannot tell “untouched” from “must not touch.” A classic supervisory-control failure is automation not knowing about the operator’s compensation, and writing the compensation off as noise.

Forward handoff wants state and cause; reverse wants them too. The difference is the giver is now a person, and people will not spontaneously write a brief, so the UI has to fold “what you changed” into a confirmable handback slip, rather than hoping they remember to dictate it.

Studying it

Task: person takes over → changes several things (including one that exists only as a decision, no field edit) → hands back. Compare no slip, auto-listed field edits, field edits plus a forced declaration of skipped steps. Dependent variables: whether the system undoes the person’s edits after handback, whether it repeats a skipped step, whether the person realises the system does not know about that decision.

Align logs: the person’s intent list versus the path actually run after handback. Every mismatch is a hole in the reverse protocol.

Where it stops holding

If the person only looked and changed nothing, the slip can be an empty confirm, but “no changes” must still be walked through, so the system does not read “looked” as “edited.” Continuous shared control with no clear handback point needs ongoing sync, not one slip. What a forward brief contains is not developed here.

Applying it

• Before handback, auto-list observable edits (fields, objects, permissions) and offer a slot for “I also skipped / voided.” Without this slip, the system must not take execution back.
• After taking back, the system must overlay its old plan with the slip, not treat the person’s edits as a conflict to “correct.”
• Check: have a person edit one field, verbally decide to skip a step, then hand back. If the system performs the skipped step, or reverts the field, reverse handoff is not yet designed. Run once more with the slip removed, and see whether every hole appears — that is how you know the slip is not decoration.

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.6 The system hands off when it loses its grip, which is when the situation is most complex · L4.04.7 Responsibility transfers immediately after handoff; the transfer must be confirmed by the taker, not assumed
• Nearby: L4.14 Plan Visibility and Revision for Multi-step Tasks · L3.12 Editing and Taking Over Generated Content · L4.05 Interruptibility and Rollback
• Search terms: reverse handoff · handback · operator compensation