Misjudging the capability envelope is the most common outcome of mode confusion

What it is

Once the mode is misread, the most common next step is not a trip to settings. It is driving as if the system could do what it cannot: treating driver support as permission to look away, waiting for a lane-centering feature to change lanes, keeping hands off in a work zone, on a ramp, or on an unmarked road. That is misuse and overtrust, not a missed toggle. The ceiling risk of confusion is getting authority itself wrong. In behavior, the path most often taken after that error is inflating the envelope. Under-use (not using it when one could) happens too, but less often drives the car into a conflict the system will not handle.

Why it happens

People extrapolate from recent success. A smooth centering becomes “it can drive”; a successful lane change becomes “it will stop at lights.” Automation bias cuts checking; a long uneventful stretch then cuts monitoring. An interface that speaks in a wheel glyph, a blue halo, or “autopilot on” names a part as a whole and feeds the extrapolation. A capability envelope is negative information—what the system will not do—and negative information has no natural sampling point inside a successful experience unless the interface says it. So the everyday shape of confusion is not dramatic “I have no idea whether it is on.” It is “I think it is on, and I think it can do more.”

Studying it

In a simulator, give a system clearly smaller than full driving (center only, no cones, no ramps) and watch whether people stay out of the loop past the boundary, and how they describe what it will do.

Independent variables: true envelope, holistic versus itemized copy, number of prior successes. Dependent variables: hands-off or eyes-off past the boundary, verbally inflated capability lists, distance from first excursion to conflict.

In crashes and near misses, check whether “I thought it would…” points at the envelope rather than at on/off. Highly visible cones in the lab understate misjudgment in real work zones. A high trust score is not itself misjudgment—trust can be calibrated; test whether trust exceeds the actual envelope.

Where it stops holding

When the system truly is close to full function on that road and ODD exit has enough lead time, there is less room to inflate, and risk returns to the takeover window. Under-use is annoying and seldom has a crash as its first consequence. Professional test drivers told to probe the boundary are not misjudging when they cross it. With no driving automation, this envelope does not exist; that is ordinary misreading of speed and road. A robot’s “one success inferred as a general ability” is the same extrapolation aimed at a different object—highway lateral and longitudinal control, not whether a service robot will open a door.

Applying it

• Speak in itemized capabilities: “holds the lane, does not change lanes,” “follows, does not handle a stopped obstacle.” Do not let “autopilot on” cover undelivered behavior.
• When a typical unhandled boundary (ramp, works, no markings) is approaching, make “it will not do this here” a short cue distinct from on/off, rather than warning only after the excursion.
• After a success, keep the interface in the itemized state; do not graduate the look to something more omnipotent because the last minute was smooth.
• Verify by listing three things this vehicle will not do, and counting how many drivers—UI only, no manual—still think it will. That share is the inflated-envelope surface.

Related

• Within the group: K6.12.1 OEMs do not share one functional boundary for the same automation level · K6.12.3 Multi-channel status cues prevent misjudgment better than a single cue · K6.12.4 Temporary capability degradation must be as salient as a full shutdown
• Adjacent: K6.09 Expressing Automation State · X3.02 Communicating Capability Boundaries · L4.02 Automation Bias
• Search terms: capability envelope · automation misuse · overtrust · mode confusion