Control transfer needs an explicit moment rather than an ambiguous gradient

What it is

Atomic control transfer changes primary authority at one recognisable, logged commit point. Preparation may be gradual, but execution must not leave both parties believing the other is responsible or both issuing primary commands.

Why it happens

Authority has discrete consequences for accepted input, constraint monitoring, and cancellation. A fuzzy transition lets display, controller, and mental model update at different times, creating gaps or dual input. One commit event synchronises routing, display, and accountability, with failure returning to a known state.

Studying it

Atomic, gradual, and implicit transfer can be compared under delay, distraction, and workload using mode judgement, conflicting commands, uncontrolled duration, recovery, and attribution. Human input, machine input, authority, and output require synchronised logs, including partial update faults.

Where it stops holding

Shared-control weight change is not necessarily primary transfer, but altered veto or duty still needs clarity. Emergency protection may seize execution immediately yet must be visible and recorded. An explicit commit does not remove preparation time.

Applying it

• Define request, acknowledge, commit, and complete; only commit changes command routing and responsibility.
• Update controller, display, and log from one transaction; retain the prior controller if a critical acknowledgement fails.
• Inject delay and partial update to detect dual command, authority gap, and display–backend mismatch.

Related

• Same group: X4.06.2 The receiving party must confirm readiness before transfer · X4.06.3 Failed or unconfirmed transfer should preserve the existing controller · X4.06.4 Frequent control transfers erode confidence in who is in control
• Adjacent: X4.05 Takeover and handoff · X4.04 Shared control
• Search terms: atomic control transfer · handoff protocol · mode transition