Mid-stream self-correction lets users see intermediate content that will later be overturned
Aliases: visible retraction · streaming take-back · overturned intermediate
What it is
The model writes a number, two seconds later another; it first agrees “can send,” then the later text becomes “please check first.” Non-streamed, those intermediate sentences die in a buffer. Streamed, they are broadcast. Visible retraction lets people see a text the system will not later own — a text that may already have been read, believed, copied away.
Judging a prefix is the person evaluating early. Here the system puts a sentence it will overturn onto the screen.
Why it happens
Decoding is locally greedy plus later constraints: a tool result returning, a self-check, a late safety layer, all can turn after a prefix already emitted. Streaming protocols usually only append; they do not offer user-side semantics for “take back tokens 17–23.” Even if a strike-through or a whole-span replace follows, the first glance has already encoded. Memory and the clipboard do not automatically follow a strike-through.
Trust harm is asymmetric. Watching a system deny what it just said reads uncertainty as dishonesty, especially when what is overturned is a number or a promise. Non-streamed delivery hands over a final draft; contradictions inside it at least happen in one time slice, and people review one document.
Studying it
Plant a mid-way retraction (a number, a yes/no promise), stream it, allow copy. Dependent variables: whether the overturned version is remembered, whether the old number is carried downstream, ratings of honesty. Independent variables: whether the retraction has a strike-through or an explanation, whether the old sentence is still in the DOM to be copied.
Measure the clipboard, not only the screen. An old sentence in the DOM is a separate leak.
Where it stops holding
A product that deliberately shows a chain of thought wants retractions as a feature, but they must visually belong to draft/reasoning, not mix into the answer layer that will be sent. Flickering suggestions in code complete are another regime; users do not take them as promises. If a stream only commits at sentence boundaries, retractions can be kept inside a sentence, at the cost of a slower first token. This entry does not treat whether long jobs should stream.
Applying it
- Commit the answer layer at sentence or paragraph boundaries. If a reasoning layer must be visible, give it another style, and do not let it one-click copy into “the answer.”
- When a retraction happens, take it back explicitly: strike-through plus “corrected to,” and let copy receive the corrected version.
- Hold numbers and promises until constraints have arrived before writing them into the answer layer. A second late is better than a promise taken back.
- Check: stream a wrong amount then retract it. Ask what the amount is, and what is on the clipboard. If the old one is still in a mouth or a clipboard, the retraction is leaking. Then see whether an old span in the DOM can still be selected.
Related
- Same group: L1.12.1 Generation latency sits in the felt-wait band · L1.12.2 Streaming shortens TTFT, not duration · L1.12.3 Streaming invites premature judgement · L1.12.5 Long background jobs should not stream
- Nearby: L3.11 Streaming the generation process · L1.06 Graceful degradation of AI failure · L5.04 Collapse of trust
- Search terms:
visible retraction·mid-stream correction·streaming take-back
Cards in the same group
- L1.12.1Generation latency usually sits in the seconds people can feel waiting but will not yet abandon
- L1.12.2Streaming shortens time-to-first-token, not total duration; it changes perception, not fact
- L1.12.3Token-by-token invites users to start judging before the result is complete, so decisions rest on a half-product
- L1.12.5Long background jobs should not stream; they need progress and permission to leave