System state must be clear the instant takeover completes

What it is

The instant takeover completes, the interface must say who holds control, what the system is still doing, and which supports have already left. The person has just been pulled out of a non-driving task; working memory still holds the video or the conversation, not a menu to audit. If the cluster keeps its automated-driving color, the steering light bar stays on, and the center stack still reads “driving,” people will drive as if the system is still helping—after lateral or longitudinal control has already been returned. This entry is that one frame of announcement. It is not the requirement that automation level stay glanceable for the whole trip; that is continuous visibility, in force when no handoff is underway.

Why it happens

Takeover turns a supervisor into an operator faster in law than in perception. Wheel torque returning and the accelerator responding again, unpaired with an interface change, get read as “the system is still there, the road just got harder.” Partial exits are worse: lateral gone, longitudinal still on, or the reverse. People generalize the half that still works into “the whole stack is still on.” Those same seconds are the densest for conflict; there is no spare capacity for a second check. So the state has to appear, in that frame, in a code that cannot be confused with “automation is driving”—color, icon locus, and light-bar on/off must jump, rather than leaving the same “assist” badge and changing a line of small type.

Studying it

After a TOR in a simulator, vary the interface: switch to manual encoding immediately, delay the change by a few seconds, change copy but not color, or drop lateral and longitudinal separately while keeping a single badge.

Independent variables: delay of the state change relative to completed takeover, whether encoding shares parts with the automated look, whether partial exits are announced per channel. Dependent variables: second hands-off or missed pedal after takeover, accuracy of a spoken “who is driving now,” path stability in the first seconds, waits for a steer or brake the system will not make.

Ask “is the system still on?” immediately after takeover; a few seconds later people have already inferred from the road, and the questionnaire no longer tests the interface. Some participants judge from wheel feel rather than the display; separate “knew from the UI” from “guessed from dynamics.”

Where it stops holding

There is no post-takeover frame if the trip was manual throughout. After a completed minimal-risk stop at zero speed, the announcement is a parked state, not “please keep driving.” Shared control or residual steering assist fights a blunt “you are fully off”; those cases need “assist remains, decisions have been returned.” Robot and teleoperation handovers also require a clear post-handover state, but the in-vehicle frame still has a forward roadway and speed attached—cabin light languages from those domains are not a completion condition here.

Applying it

• Switch cluster and light-bar encoding at the same moment takeover is judged complete (torque, pedals, or driver confirm); do not wait for the next screen refresh to change color.
• If lateral and longitudinal can exit separately, use two indicators; do not let one “autopilot” badge cover both half-exits.
• Copy in that frame should say “you are driving,” not “assist ready,” which still sounds like the system is on duty.
• Verify by pausing or interrupting immediately after takeover and asking who controls steering and who controls speed. Every wrong answer is a frame that still looks automated.

Related

• Within the group: K6.08.1 Takeover needs enough lead time · K6.08.2 Takeover alerts need redundant channels
• Adjacent: K6.09 Expressing Automation State · X4.05 Takeover and Handoff · X4.06 Explicit Transfer of Control Authority
• Search terms: post-takeover state · control authority · mode awareness · automation surprise