A local edit has to locate the part the user meant; failed reference is the main break

What it is

The user says “change that number in the second paragraph to last year’s.” Before any rewrite, the system has to know which paragraph and which token those words pick out in the current output. If they do not line up, the local edit has already failed. That break is referential grounding failure: the pointer in language and the span on screen are not the same object. It is not poor generation quality. It is a wrong address.

Clicking, boxing, parking the caret in the target sentence, are all ways around that sentence. A local edit in language alone is a coreference problem every time.

Why it happens

Pointing in conversation depends on joint attention. A finger can pin an object; a text-only channel leaves pronouns, ordinals, and vague descriptions. Every rewrite moves paragraph numbers, sentence boundaries, and repeated figures. “Second paragraph” in the user’s memory still names the old span; in the new text it is already another paragraph. A system that resolves only against the latest text is using the wrong coordinate frame.

There is also a silent form: the system picks a span that will do (the nearest number, the longest block) and the rewrite looks like success. When the user notices the wrong place moved, they file the error as “local edit does not work,” not “it guessed the wrong address.”

Studying it

Build edit instructions with ambiguous pointers: the same number appears three times, paragraph order was shuffled last turn, “that” could be the title or a footnote. Have the system or a participant mark the span that will change, and compare it with the author’s target span. Independent variables: pointing method (language only / click / language plus click), whether the previous rewrite scrambled structure. Dependent variables: span intersection-over-union, wrong-object rate, whether the user notices the wrong place moved.

Do not use final text quality alone. A correctly located, clumsily worded edit and a beautifully worded edit in the wrong place are different failures of the local-edit function. Eye tracking or click heatmaps show whether people try to pin an object before they speak — if the UI offers no pin, heat falls on the input field, not the body.

Where it stops holding

When the output is tiny and there is only one editable object, reference almost cannot fail and this entry will not show up. Image or timeline tools that already take the address out of language with a box or a scrub move the failure to selection precision, not pronouns. Legal text and tables with stable numbering make ordinals much safer; prose and reshuffled lists are the wreck zone.

Applying it

• Offer a pin: click a sentence, drag a span, box a region on an image. Highlight the pinned region before send so the user sees the address that will change.
• If a language-only pointer has several candidates, list the candidate spans and let the person pick. Do not silently pick one that will do.
• After a local edit, mark the span that actually changed. A change outside the indicated span is a wrong address; allow a revert of that span only.
• Check: prepare ten edits whose pointers are ambiguous (repeated entities, ordinals after a shuffle). Without clicking, count wrong-object edits; with clicking, the same set should drop. If clicks still often change text outside the highlight, the locator is not wired to generation.

Related

• Same group: 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.4 Any historical version must be restorable; undo-last-step cannot carry iteration · L2.12.5 The cost gap between local and full regeneration should be visible to the user
• Nearby: L2.05 Iterative Revision · L2.15 Ambiguity and Clarifying Follow-ups · L3.12 Editing and Taking Over Generated Content
• Search terms: referential grounding failure · anaphora resolution · local edit span