The later the escalation, the longer the execution history a person must reconstruct

What it is

From the first cannot-do to a person seeing it, every extra beat left in the middle adds a stretch of history: one more retry, one more reroute, one more object changed. To rebuild the situation far enough to handle the gap, the person has to walk that stretch. Later escalation means longer replay treats the escalation clock as a controller of reconstruction cost: early, short gap, little wreckage; late, takeover becomes reading history.

Compressing into three columns eases reading. It cannot unhappen steps that already ran. The cost of late sits in the world, not in the copy.

Why it happens

Situation reconstruction time is a hard constraint; the input volume is history length. Late escalation raises that volume one way: retries write more events, an approximation may already have handed a wrong artefact out, the partial list is longer. People are not unable to handle a late ask; the window they need grows with history, while products still open the takeover window as if it had “just failed.” This is two ends of the same chain as retry delaying a person seeing it: delay is the clock; length is the paper on the desk when the clock has run.

Early escalation is not nagging. It is locking reconstruction near the first failure.

Studying it

Set escalation delay to 0 after first failure, after k retries, after task timeout. Dependent variables: time for a person to rebuild far enough to handle correctly, number of steps read, how often already-done steps are harmed, subjective “I am reading history.” Independent variables: whether the packet is already compressed to the gap, whether the process view defaults to the failure point.

Reconstruction time should regress on delay. If compressing copy barely lowers reconstruction time, the cost is in event volume, not in narration.

Where it stops holding

Bounded retry on a transient fault introduces a small delay; if event volume stays short and visible, reconstruction cost is acceptable. When an irreversible outward consequence has already landed, late is not only long — the world has already changed, and a longer rebuild window will not take it back. How the gap is written, how the cleanup list is attached, eases reading, not the events themselves. Sudden handoff stacked on late escalation is worse, but sudden is startle of timing; this is quantity.

Applying it

• Write “first cannot-do → person sees it” as a deadline. Inside the deadline, only transient retries are allowed. At the deadline, escalate, however much the inside still wants to try.
• A late escalation should default the process view to the first failure point, not the last retry, so people do not flip backwards from the end.
• Check: compare reconstruction time for escalate-on-first-failure versus escalate-on-timeout. If the latter is substantially longer, the clock is manufacturing history-reading. Pull the deadline back to the first persistent failure; reconstruction time should drop with it — if it drops, late was the cause, not people reading slowly.

Related

• Same group: L4.13.1 When an agent cannot finish, it should escalate rather than cover with an approximation · L4.13.2 Escalation must say which step is stuck and what is needed; a failure report alone cannot be handled · L4.13.3 Retrying without escalating consumes resources and delays human intervention · L4.13.4 A partially completed task must say how far it got and whether cleanup is needed
• Nearby: L4.04 Takeover and Handoff Design · L4.08 Visibility of Task Progress · L4.12 Task Progress and Intermediate-state Visibility
• Search terms: escalation timing · situation reconstruction · handoff