Responsibility transfers immediately after handoff; the transfer must be confirmed by the taker, not assumed

What it is

The moment control passes, organisations often write duty across too: from this second a failure is the taker’s. Responsibility transfer must be acknowledged requires that transfer to be an explicit acceptance, not a countdown finishing and the system unilaterally declaring “handed over.” A person who has not yet caught the baton already carrying the duty is a witness rewritten as the accountable party.

A transfer that holds by default is the same misalignment as a nominal human loop: a person on the paper, not in the causes.

Why it happens

Handoff has two contracts. One is control: who can change the world. One is duty: whose name is on a failure. The system can push control before the person understands (even before they have touched a key), while the duty clause starts at the push. If the taker has no “I have it” act, the two contracts’ start times are aligned by the system alone. Aviation handovers have the taker read back key items — not politeness, but making acceptance an observable event, so the duty clock starts when read-back completes.

Timeout-defaulted takeover turns acceptance into silence. Silence can be written as consent in legal copy; cognitively it is “still reading.”

Studying it

Compare three transfers: duty starts only after explicit acceptance, starts on timeout default, starts when the system announces. Then plant a fault and ask taker and bystander “whose is this second.” Independent variables: whether read-back of key state is required, timeout default direction (counts as taken versus not). Dependent variables: attribution of duty, whether people dare act before acceptance, whether “I thought it was not yet mine” appears.

Ask attribution and actual control separately. People may already be able to change the world and still think duty sits with the system — that split is what the design has to close.

Where it stops holding

A freeze after an emergency stop can halt the world first, with duty still on the system until the person explicitly takes over to continue. Continuous shared control (the person can change at any time, the system is also running) needs another shared-duty rule; a single transfer cut will not do. Mapping of level to duty is a ruler question; this entry only treats when the clock starts at the moment of passing control. Whether the person has the conditions to refuse is a separate traceability claim.

Applying it

• Split transfer into two moments: the system offers, the person accepts. Before the second, do not give execution — or give only look-and-stop — and do not write duty onto the person.
• Acceptance must be an observable act, with a record. A timeout default can only be “the system still holds,” never “counts as you took it.”
• Check: plant a fault before the person has pressed accept, and see whose name the later record puts on it. If it is the person’s, the clock started early. Then ask the person on shift “have you taken over now” — if that disagrees with the record, the transfer is assumed, not confirmed.

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.8 Reverse handoff needs design too; when a person hands back, they must say what they changed
• Nearby: L4.15 Accountability and Traceability · L4.01 Levels of Automation · L1.05 Human in the Loop
• Search terms: takeover acceptance · responsibility transfer · handoff