Observable intermediate steps turn after-the-fact correction into in-process intervention

What it is

When an error is found decides how expensive the repair is. Seen only at the finale, repair is redoing the bundle or correcting outward; seen in intermediate steps while it runs, repair is changing the next beat. Mid-steps shift correction in-process is a timeline move: the value of visibility is not “knowing where we are,” it is correction happening before a crossing, inside the same task.

A complete after-the-fact log only speeds diagnosis. It does not take the error off the world.

Why it happens

Correction cost rises with how many times a world boundary has been crossed. Intermediate steps expose a future not yet crossed, so a change can act on the future rather than the past. This is a second use of the same window that lets intervention aim at a beat: aiming is targeting; moving the timeline is shifting the whole of correction from after the task ends to while the task is still going. The mark of a successful move: for the same class of error, the share caught in-process rises and the share found only at the finale falls.

If the window opens only after the end, the timeline does not move. If the window is open but the person can only look, not change, it does not move either — in-process intervention still needs an entry to change, not only to abort the show.

Studying it

Hold the same class of object error, compare: finale-only visibility, process visible but only whole-show abort, process visible and the next beat editable (swap object, skip, change a parameter). Dependent variables: how often the error happens outward, in-task repairs, total time to finish. Independent variables: whether an entry to change the next beat exists, whether the step pauses before the crossing.

The primary endpoint is outward occurrences, not subjective “I can follow.” Following but unable to change means the timeline did not move.

Where it stops holding

Steps so dense they cannot be followed fail the move; people can only rummage a log afterwards. If what is shown is not the real path, people will change the wrong thing at the wrong moment. Revising a plan before execution moves correction one slice further forward — that is plan visibility, not in-process. This entry requires that after execution has started, correction can still land on a future not yet crossed.

Applying it

• On the process view, before each beat crosses, offer the trio “change this object / skip / stop,” not only whole-show abort.
• Count when errors are found: in-process versus finale. If the in-process share will not rise, the window is still a monitor, not a correction surface.
• Check: put a wrong object at step k. The person should change it before k crosses, the task continues, zero outward errors. If they can only stop the whole show and restart, the timeline is still after the fact.

Related

• Same group: L4.12.2 Steps that are too dense exceed the user's ability to follow; visibility degrades into a scrolling log · L4.12.3 Users need to tell where they are in the plan and how much remains · L4.12.4 Displayed steps must be the real execution path; a fabricated process misleads when to intervene · L4.12.5 Long phases with no output need their own explanation, or they will be judged as stuck
• Nearby: L4.08 Visibility of Task Progress · L4.05 Interruptibility and Rollback · L4.14 Plan Visibility and Revision for Multi-step Tasks
• Search terms: in-process intervention · intermediate state · correction timing