Any historical version must be restorable; undo-last-step cannot carry iteration

What it is

The user likes the structure in version 3, the ending in version 7, and version 8 just broke the structure. Ctrl+Z only returns version 7. Version 3 is unreachable unless the gains of 4 through 7 are thrown away with it. Any-version restore is not the same grade of ability as “undo the last step.” Iterative editing walks a version tree; linear undo flattens it into a stack that can only step back one. That stack cannot carry this walk.

A browsable history list is not restore. Seeing version 3 but only being able to copy-paste the whole block still drops the one paragraph that was already right in version 7.

Why it happens

The value of generative iteration often sits in local peaks along the path: one version’s outline is right, another version’s example is right. People need random access, not a stack. Linear undo assumes each step improves the current state, so stepping back cancels the latest mistake. That assumption fails in exploration — step 8 can be a failed experiment while step 3 is still the skeleton to keep.

There are also branches: starting a “different audience” path from version 3 should not overwrite the original path. An interface that can only undo the last step forces a choice between overwrite and abandon, so people start saving outside the editor and iteration leaves the product.

Studying it

Set a task that requires “taking the best of two points on the path”: the structure of version A plus a passage from version B must both appear at the endpoint. Compare an interface with only linear undo against one that can restore any version by clicking it. Dependent variables: task completion, whether text is copied out of the product, the distribution of how far back the restore target sits from current.

What people actually want to return to is not n−1, it is an earlier peak. If the mode of that distance is greater than 1, linear undo picked the wrong model. A lab that bans external documents will under-count the real rate of “copy out and use as a version store.”

Where it stops holding

A two-step flow is fine with linear undo; any-version restore is overload. If a collaborative document already has a full version history, the product should join that history rather than keep a generate-snapshot that can be viewed but not restored. Storage and privacy cap retention; when a version cannot be kept forever, say “version 3 has expired and cannot be restored” so people can pin it before it goes.

Applying it

• Write an immutable snapshot on every generation. Any item in history can become the current working copy in one click, without first undoing the steps in between.
• Allow a branch from a snapshot rather than overwrite. The current path should be visible in the history.
• Keep undo-last-step as a shortcut; it must not be the only way back to an older result.
• Check: run an edit at least eight versions deep, then require a return to version 3 without losing a separately saved fragment from version 7. If the person must mash undo and redo the work of version 7, the function fails. Watch logs: a spike in “copy all” in the later edits means the clipboard is being used as a version store.

Related

• Same group: L2.12.1 A local edit has to locate the part the user meant; failed reference is the main break · L2.12.2 Changes in parts that were not mentioned destroy trust in the edit function · L2.12.3 Successive edits accumulate drift until the result no longer matches the original goal · L2.12.5 The cost gap between local and full regeneration should be visible to the user
• Nearby: L2.05 Iterative Revision · L2.07 Prompt History and Reuse · L1.11 Reproducibility of Non-deterministic Output
• Search terms: any-version restore · selective undo · generation snapshot history