Users must be able to correct the part that was misunderstood

What it is

Booking a table, the system hears 7 p.m. as 11 p.m. and echoes the whole party: four people, window, eleven. The user must be able to change only the time, not be forced to restate party size and window. User-initiated partial repair makes “correct the misunderstood constituent” a dialogue act: the person points at the wrong piece, the system reopens only that piece, and already-grounded slots stay. Without that path, the person who found the error can only restart the ticket or live with the wrong item. How to word the admission of mishearing is a different layer. This one is whether the state machine will let one item be changed.

Why it happens

Once a slot in common ground is treated as grounded, the default is not to reopen it. The user’s correction is other-repair: aimed at a constituent the system just displayed. Three jobs have to succeed to catch it — recognise this as repair rather than a new task or a new order, aim the repair at the right slot, and unground only that slot. Fail to recognise, and “not eleven, seven” becomes a second booking. Aim wrong, and party size changes. Unground too wide, and window dies too. Repair often arrives without a slot name (“seven,” not “change the time to seven”); aiming leans on contrast with the just-echoed form: which filled item is the same type as the new value, which one conflicts. Echo is therefore not politeness. It gives repair a target that can be pointed at. An error that was never displayed cannot be aimed at, and partial repair cannot start.

Studying it

In a slot-filling task, inject a substitution on a known slot, let the system echo the whole ticket, and watch whether the user’s correction hits that slot and only that slot. Independents: whether the wrong slot appeared in the echo, whether saying only the new value is allowed, how many other slots are already filled. Dependents: rate the correct slot is repaired, rate an innocent slot is cleared, rate of giving up and restating the whole ticket.

In corpora, tag “immediately after a system echo, the user gives a new value of some slot’s type” as repair initiation. See whether production treats it as a new intent. Wizard-of-Oz can measure, before NLU is sturdy, whether people naturally fix only one piece when they can hear the echo.

Where it stops holding

If the user has heard no echo, they cannot know which piece is wrong; demanding partial repair is unfair — display, then repair. When every slot is wrong (the whole utterance collapsed), there is no basis to keep, and a full restart is right. Items locked by law or inventory (an already-issued ticket number) cannot be ordinary-slot reopened by mouth; they take an explicit change path. A repair that is only reachable by saying “modify booking” to enter a sub-skill is, for most people, no path. Spoken editing on the input channel (fixing the last dictation) sits next to changing a dialogue slot; they are not the same state machine.

Applying it

• On the turn after an echo, treat a new value that conflicts with, or is the same type as, a filled slot as repair of that slot. Do not open a second ticket.
• After a hit, mark only that slot ungrounded; leave the rest. Confirm the new value in a short echo so the next aim still has a target.
• If the user names the slot (“the time is wrong”) without a new value, reopen only that slot; do not walk from the first empty slot again.
• How to check: four people, window, 7 p.m. heard as 11 p.m. User says “it’s seven.” Party size and window should still be there; time becomes seven. Whole ticket reset, or party size changed: partial repair did not connect.

Related

• Same group: M1.06.2 Partial correction beats repeating the whole utterance · M1.06.3 Consecutive failures must change strategy, not repeat the same prompt
• Nearby: M2.04 Error-Recovery Wording · C7.13 Voice Editing and Spoken Correction · M1.05 Topic Switching and Task Nesting
• Search terms: user-initiated partial repair · other-repair · slot-level correction