Regenerating after the user has taken over will overwrite human edits unless a merge rule is explicit

What it is

Paragraph three was changed to the client’s real numbers. “Generate” is clicked again; the whole piece is new; the numbers are gone. People thought generation would continue on the unedited parts; the system treated the document as a fresh blank target. A merge rule on regenerate requires that if generation is still allowed after takeover, how the new output meets human edits must be said in advance — overwrite, juxtapose, fill only unedited regions, stop on conflict — not left for people to discover afterwards that “what I changed is gone.”

Draft or finished decides whether people dare to edit. Here the edit already happened; the question is how the next generation treats those edits.

Why it happens

A generation endpoint by default eats a prompt, not “current document minus human patches.” If regenerate samples a whole new piece, the patches are not in the condition and will be covered. People’s mental model is the opposite: words in an editor are stable; new generation should “write further” or “only change my selection.” The two models meet on one button; with no rule, the system default runs — overwrite.

Overwrite hurts especially because edits are often already-checked slots: numbers, names, legal phrasing. What is covered is not style; it is content whose checking cost has already been paid.

Studying it

Have people edit several slots, then trigger regenerate. Compare whole-piece overwrite, generate-in-selection-only, three-way merge with conflicts marked. Dependent variables: whether checked slots remain, whether people notice overwrite, whether they dare click generate again. Independent variables: whether the rule was stated in advance, whether edits are highlighted.

“Dare not click generate again” is the behavioural consequence of a missing rule and should be reported separately.

Where it stops holding

When the user explicitly wants “start over,” overwrite is requested; still warn that edited content will be discarded. A read-only viewer has no takeover and no merge. Local regenerate whose selection contains no human edits simplifies to “outside the selection does not move.” Two people editing at once adds interpersonal conflict beyond a single-user rule. This entry does not treat whether edits should be attributed.

Applying it

• Before regenerate, detect human edits in the document. If any, forbid silent whole-piece overwrite; offer generate-in-selection / new draft beside / list of edits that will be lost plus confirm.
• Put the rule beside the button, not in help. “This will replace paragraphs you edited” must be visible at action grain.
• Default to protecting edited slots; new generation fills unedited regions. On conflict, stop for a pick; do not let the model win automatically.
• Check: change a number, then regenerate. If the number vanishes with no confirm, there is no merge rule. If the number remains and the new draft sits beside, the rule is working.

Related

• Same group: L3.12.1 Whether a generated artefact is framed as a draft or a finished piece decides whether the UI should lean editor or viewer · L3.12.3 Human edits should be marked, or afterwards no one can tell which stretch came from whom · L3.12.4 The higher the takeover threshold, the more people settle for a result they dislike · L3.12.5 Editing a generated artefact can take more skill than writing from scratch, because the existing text must be understood first
• Nearby: L3.13 User Feedback Loops on Generation Quality · L2.12 Iterative Edits and Local Regeneration
• Search terms: overwrite vs merge · regenerate after edits · protect human patches