After the user edits the result, later turns must respect those changes

What it is

The user changes a wrong company name in the draft; the next turn only says “make it shorter.” Generation puts the old name back, because the model is still conditioned on its own last output and never took the keystrokes as a new fact. Later turns must respect in-place edits. If they do not, the editor is temporary: the person changed it and did not; the next generation overwrites the labour.

This is not the general side-effect “do not touch unmentioned parts.” It is a harder rule: characters the person has already written are a veto of the system’s output, and must not be generated back by default.

Why it happens

Multi-turn generation’s default state is “latest model output.” If keystrokes only patched the DOM and were not written back into dialogue state, the next request still carries the model’s own previous copy. Even when the edit is spliced into the prompt, the model may treat it as polishable draft and overwrite it with the smoother old name. The screen’s source of truth and the model’s source of truth split.

People hear typing as submitting a fact. Overwriting that fact is read as the system choosing to forget a correction, which hurts more than an ordinary stray rewrite, because it denies the act “I edited this” itself. After that, people refuse to edit inside the product and move to an external file; the loop breaks.

Studying it

Split the protocol in two: first have the person change one fact on the artefact (a proper name, a figure, a negation), then send a rhetorical instruction that does not mention that fact. Check whether the fact survives verbatim in the new output. Independent variables: whether the edit is written into the request, whether it is marked as a non-overridable constraint, distance between the instruction and the edit. Dependent variables: edit survival, whether the user keeps editing in-product after noticing an overwrite.

Overwrites sometimes change a synonym and the proper name happens to vanish; align rather than demand string equality, so a legal expansion is not counted as failure. Shrinking back to the old wrong name is always a failure.

Where it stops holding

If the user changed style rather than fact (“您好” to “嗨”), a later “make it more formal” should be allowed to restore the honorific; otherwise respect locks in a probe. Fact edits and probe edits have to be distinguished, with an explicit mark or by treating “changed a number / changed a name” as fact by default. In collaboration the later writer may overwrite the earlier one; that is permissions, not model respect. Empty edits (whitespace only) should not trigger a lock.

Applying it

• Mark user-typed spans as confirmed facts and send them with later requests as a hard constraint, not merely as a screen update.
• If a later instruction conflicts with a confirmed fact, stop and ask which side to follow. Do not silently let model output overwrite keystrokes.
• When an overwrite happens, offer “restore the place I changed” rather than undo-all, and label that span in the diff as “you wrote this.”
• Check: change a proper name in a draft, then send three instructions that never mention it. The name must keep the user’s spelling in all three. Any return to the model’s old name is an overwrite incident. Then watch whether in-product edit events stop after the overwrite — a stop means the person has judged in-product editing void.

Related

• Same group: L2.13.1 If the output cannot be edited, the user can only accept it or start over · L2.13.3 Too many control dimensions turn a generation tool into specialist software that has to be learned · L2.13.4 Different expertise needs different grain; grain should be switchable, not one size
• Nearby: L3.12 Editing and Taking Over Generated Content · L2.12 Iterative Edits and Local Regeneration · L2.14 Carrying and Clearing Context
• Search terms: respecting in-place user edits · sticky human edits · edit overwrite