Steps that are too dense exceed the user's ability to follow; visibility degrades into a scrolling log

What it is

Flush every function call, every token, every internal retry onto the screen, and people cannot follow. The window is still there; supervision is already dead. Overly dense steps become a log: visibility holds in letters and fails in following. People retreat from “watch this beat” to “wait until it stops and search.”

Scrolling text gives a feeling of process transparency. It does not give the ability to aim an intervention.

Why it happens

Following needs the current step in working memory, aligned with a place in the plan. When flush rate exceeds reading, working memory always holds a stale previous line. People give up on real time and switch to search after the fact — the timeline move is cancelled by density itself. A log has value as an archive, none as a supervisory surface. Grain should stop at the layer where a person can judge “should this beat continue”: acts on external objects, entering and leaving plan nodes — not every hop of internal inference.

Observability asks whether a window exists; density asks whether the grain inside the window can still be used as a supervisory surface.

Studying it

Hold the same task, compare three grains: tool-level (each external call), plan-node level, full internal events. Dependent variables: whether the current object can be named mid-way, in-process corrections, whether people switch to searching the log after, subjective load. Independent variables: refresh rate, whether fold and filter exist, whether the current step is pinned.

“Switched to searching the log” is the behavioural mark of density failing, harder than satisfaction.

Where it stops holding

A debug role needs the full log; that is another view, not to be mixed with the operator’s supervisory surface. A task of two or three steps cannot get dense. Where we are in the plan and how much remains can only be asked at a followable grain; if grain explodes first, there is no sense of progress either. Silent phases judged as stuck are no output; density is too much output. Opposites.

Applying it

• Operators default to plan nodes and acts on external objects. Internal retries, tokens, debug events go in an openable log, folded by default.
• Pin the current step in the viewport; new lines must not push it off. If people lose “now” while it flushes, density has already won.
• Check: mid-way, ask the current object. If they cannot answer or go searching history, it is too dense. Pull grain back to node level and ask again — if they can answer, see whether in-process correction has returned. If correction has not, pin or the change entry is still missing.

Related

• Same group: L4.12.1 Observable intermediate steps turn after-the-fact correction into in-process intervention · 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 · L5.05 The Moderation Principle of Transparency · L4.14 Plan Visibility and Revision for Multi-step Tasks
• Search terms: followability · log vs status · granularity