L1.12.4mid-stream self-correction shows overturned contentdesignresearch

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

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/L1.12.4