Undo and redo lose their meaning when output cannot be reproduced; undo does not return the earlier result

What it is

Undo’s contract is: return the previous world, and that world still exists. Redo walks the same contract forward. If a generated result lives only in that one sample, and the interface stored only the instruction “run this again,” undo will produce a different world. Undo collapse is not a broken shortcut. It is the undone object never having been treated as state that must be kept.

Cmd+Z is expected to show the title that was just on screen, not “generate another title.”

Why it happens

Classic document models capture each commit as a snapshot or as an inverse. Generate surfaces often capture a commit as “request again with this prompt.” Requests replay; samples do not. Undo is implemented as replay, replay meets a new random draw, and the state is gone.

Worse, some apps also push streaming mid-frames onto the undo stack, or treat Stop generating as a step. The stack then fills with unnameable half-products. What the user wants back is a completed state they had nodded at; what the stack can offer is “draw again” or blank. The contract was swapped in the implementation and still called undo.

Studying it

Task: generate → accept → generate-over → undo. Record whether the text after undo matches the accepted state byte-for-byte. Compare three implementations: replay the prompt only, keep output snapshots, keep a full sample record (prompt + seed + output). Dependent variables: identity recovery rate, whether people notice “this is not the one,” whether they become afraid to undo again.

Eye tracking and retrospective talk-aloud must separate “thought I was back” from “was back.” Surface similarity manufactures false recovery. The metric has to be a hash or a verbatim compare, not “looks close.”

Where it stops holding

If every generation is written as an immutable version (a chat bubble, a version list), undo can shrink to “move focus to the previous item” and the semantics still hold. Collapse is the in-place replace that keeps no draft. Append-only timelines are reversible by construction. In collaboration, undo also involves which version someone else has already read — a sync problem beyond a single sample. At temperature zero with the seed stored beside the result, replay can restore, provided the decoding stack is identical — a premise that shatters when the model or the server moves.

Applying it

• Every completed state the user saw must remain an immutable snapshot. Undo only moves a pointer. Do not impersonate that with “request again.”
• Before an overwriting regenerate, push the current completed state into history automatically; do not wait for the user to think of copying.
• Put only completed states and the user’s own edits on the undo stack, not streaming mid-frames.
• Check: generate A, generate B over it, undo. The screen must be a verbatim copy of A. Store A’s hash in the test. After a model bump the test should still pass — it is testing whether the product stored a snapshot, not whether the model is stable.

Related

• Same group: L1.01.1 The same input can yield different outputs · L1.01.2 Interface conventions assume actions are repeatable and results are stable · L1.01.3 Users misread a lucky correct answer as stable competence · L1.01.4 Controls promise that the same action yields the same result; generation breaks that promise · L1.01.5 Retry cannot tell whether the phrasing was wrong or the system itself is fluctuating · L1.01.7 Presenting regeneration as “refresh” implies the previous result was a failed load · L1.01.8 Presenting variability as several parallel options is more honest than hiding it behind a single result
• Nearby: L1.11 Reproducibility of non-deterministic output · L2.12 Iterative edits and local regeneration · I3.02 Optimistic updates
• Search terms: undo collapse · snapshot versus replay · non-reproducible undo