Failed or unconfirmed transfer should preserve the existing controller
Aliases: handoff rollback · unconfirmed transfer · fail-safe control
What it is
Fail-safe handoff rollback retains the existing controller and known constraints when acknowledgement, communication, or component switching is incomplete. New authority exists only after full commit; an incomplete transfer has not occurred.
Why it happens
Handoff spans messaging, permission, routing, display, and actuator, with partial updates possible. Early release creates an authority gap; dual activation creates conflict. Transactional transfer holds old state until all conditions commit, using timeout and idempotent events for loss and duplication.
Studying it
Packet loss, delay, duplicate acknowledgement, restart, and display failure should measure actual controller, dual command, gap, consequence, and recovery. Normal-network demonstrations are insufficient. Human understanding of failed transfer also matters.
Where it stops holding
If the old controller is itself unsafe, rollback enters a minimum-risk condition instead. Remote or cross-organisational operation needs final-authority definition. Retaining authority may mean safely pausing rather than continuing the task.
Applying it
- Use uniquely identified two-phase commit; release old control only on completion.
- Define one state for timeout, retry, duplicate, and receiver crash and show it consistently.
- Fault-inject to verify exactly one primary controller at every instant and a defined safe failure state.
Related
- Same group: X4.06.1 Control transfer needs an explicit moment rather than an ambiguous gradient · X4.06.2 The receiving party must confirm readiness before transfer · X4.06.4 Frequent control transfers erode confidence in who is in control
- Adjacent: X4.02 Human intervention · X4.05 Takeover and handoff
- Search terms:
handoff rollback·two-phase commit·fail-safe control