A confirm should echo only the risky slots

What it is

A confirm is a selective playback, not a second reading of the whole form. Slots already picked from a list, or heard stably from a closed vocabulary, catch no new error when spoken again, and they spend auditory bandwidth. In “four people, grandma's, tomorrow at noon — right?”, if the restaurant was just chosen from a three-way disambiguation, the risk is time and party size, not the name. What gets echoed is the slots that can still be wrong, not “everything just said.”

Why it happens

Spoken confirmation is a working-memory check: people compare the echo against their intent item by item. The longer the echo, the more serial the comparison, and middle items drop out. Each extra grounded slot is another chance to glaze over, and the dangerous number gets buried mid-sentence. Open slots (names, places, amounts, times) have high substitution rates and concrete stakes; a slot just clarified, or a binary already nodded through, already has a high prior.

Echoing safe slots also changes listening strategy: people learn that the whole sentence is boilerplate and drop a “yeah” at the end. The next time a truly dangerous slot is nested in boilerplate, the comparison is already off. Confirm length is therefore not courtesy; it is catch-area. The area should cover high-risk slots, not the whole form.

Studying it

For the same action, write two confirms: full-form readback versus echo of only open / low-confidence slots. Inject one recognition error, placed either in an echoed slot or in a silenced one. Dependents: catch rate, confirm duration, barge-in on the confirm, and whether people can repeat the key number they just confirmed.

In logs, split later undos and complaints by slot type: amount or recipient going wrong after a confirm that only asked “send it?” means the echo did not cover the risky item. Satisfaction is the wrong metric: people can find the sentence “very clear” and still not have checked the time in the middle.

Where it stops holding

First-time users of a skill may need a fuller echo to feel “it heard me”; shrink it after that. Legal or financial readback may require the full text. Implicit confirmation can usually smuggle only one slot (“okay, to the airport”); remaining risky slots still need a short explicit echo. Eyes-free with many slots, even a risk-only echo can be too long — ask “is the time right?” then “is the party size right?” rather than packing one sentence.

Applying it

• Tag every slot: open vocabulary, numbers, proper names, and low confidence are high; just selected from a clarification list, closed yes/no, and a slot the user just repaired are low. The confirm speaks only high tags.
• Ban sentences that echo only the act type (“confirm you want to book a table”) when the risk sits on time or party size.
• Do not bury several high-risk slots in the middle of one sentence. Split into two short confirms, or put the dearest slot last — the position still in memory.
• How to check: inject an error into a high-risk slot that was not echoed; if a nod executes it, the echo set is wrong. Injecting an error into a already-grounded low-risk slot and not echoing it is acceptable — if that slot really is grounded.

Related

• Same group: M2.08.1 Confirmation can target the recognized string or the action about to run · M2.08.2 Yes and no get misheard too
• Nearby: M2.01 Information density of prompts · M2.09 Matching confirmation to consequence · M3.11 Trimming speech output
• Search terms: partial readback · risky slot · confirmation echo