Time to rebuild the situation is a hard constraint and cannot be squeezed to zero

What it is

A protocol can schedule preview, a UI can make the brief shorter, but the minimum time a person needs to fold elements into comprehension and then into projection does not vanish under those moves. SA rebuild time is a hard constraint: a floor of a cognitive process, not an animation duration, not a countdown number.

Changing a takeover countdown from five seconds to two saves waiting, not rebuild.

Why it happens

Perception, comprehension and projection are serial; each layer has to eat data. A better brief still has to be read; clearer cause still has to be taken into the current model. Reading speed, attention switching, hot-starting a model from outside the loop, all have physiological and cognitive floors. Driving takeover work treats “time-to-takeover” as an input to the vehicle, not as latency a UI polish can brush off. Agent products often treat the same floor as friction to kill, and so “speed up” with shorter modals, auto-confirm, timeout-defaulted takeover. What speeds up is the process clock, not the person’s model.

The hard constraint means: if the task cannot give this floor, the person should not be designed as the actor of that beat. What should change is the automation level or the stop policy, not the countdown.

Studying it

Take preview and brief quality to what you believe is optimal, then systematically shorten available time and watch when correct intervention collapses. Independent variables: available time (from preview to must-act), whether the brief is already optimised, task complexity. Dependent variables: share of correct first beats, SA probe scores, subjective “I had not finished looking.”

Look for the collapse point, not the mean score. If the collapse point does not move much as the UI gets prettier, the hard constraint is speaking. Between-person variance is large; design to the slow still-acceptable end, not the median.

Where it stops holding

If the person has been in the loop and the model is already hot, the floor is much shorter, even a single glance. Experts with few objects and well-known failure modes also have a short floor; that expert floor must not be written into a product for newcomers. An emergency stop does not ask the person to finish comprehension inside the floor, only to complete one pre-coded act. Whether the protocol should schedule a window is a separate claim; this one says that even a scheduled window cannot be scheduled as zero.

Applying it

• Measure the collapse point on real material: with an optimal brief, how long until a correct first beat. Write that value as a product constraint; a countdown or a timeout default must not punch through it.
• If a task cannot give that time, do not design the person as having to take over execution on that beat; have the system hold on a safe default until the person declares ready.
• Check: cut available time below the collapse point; correct first beats should drop sharply. If they drop and the product still uses that time, the process clock is impersonating the cognitive clock. The collapse point not vanishing as copy gets shorter is how you know you measured a hard constraint.

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.6 The system hands off when it loses its grip, which is when the situation is most complex · L4.04.7 Responsibility transfers immediately after handoff; the transfer must be confirmed by the taker, not assumed · L4.04.8 Reverse handoff needs design too; when a person hands back, they must say what they changed
• Nearby: L1.05 Human in the Loop · L4.09 Skill Degradation · L4.01 Levels of Automation
• Search terms: takeover time · situation awareness · hard constraint