After barge-in, tell correction from a new request

What it is

The system is saying “departing Friday at ten,” and the user overlaps with “make it Saturday” — a fix to the slot currently being spoken. The same position with “play music first” drops the current sentence and starts something else. Once barge-in is detected, the incoming still has to be classed as repair versus new request. The object of the class is the utterance that cut into playback, not a negation in the next turn after the system has already finished.

Why it happens

What is currently playing is the strongest context: where the user comes in often marks which piece they are fixing. “Saturday” overlapping “Friday” is other-repair on the date slot; coming in at the start of a whole confirmation with a predicate from another skill is a new request. If dialogue management treats every barge-in as “cancel playback, take the whole utterance as a new intent,” “make it Saturday” becomes a brand-new trip and the destination already filled is lost. If it treats every barge-in as a local edit of the current sentence, “play music first” is stuffed into a slot of the itinerary.

Three things have to be read together: which slot the overlap landed on, whether the incoming contains a new value of that slot’s type, and whether it contains a predicate outside the current task. A bare negation (“no”) with no new value should open a repair of the piece now being spoken, not silently launch a new skill. Detection only decides stop-or-not; without a stop there is nothing to class, and a stop classed wrong spends the loss on task state.

Studying it

Build a mid-playback interruption corpus: elicit barge-in on marked slots of system TTS, and label incoming as repair of the current slot, repair of another filled slot, new request, or abandon. Features: overlap position relative to the current sentence, presence of a same-slot new value, presence of a new-skill predicate. See which class the production model misses, and whether the state machine then edits a slot, opens a skill, or clears.

Wizard-of-Oz can place the same string “not Friday” in two positions: overlapping “Friday at ten,” and overlapping an unrelated weather readout. The same words should land on different functions. Do not substitute off-line sentence classification that has left the playback position — without “which stretch was interrupted,” repair cannot be typed.

Where it stops holding

An utterance that both edits a slot and switches task (“skip Saturday’s flight, play music”) is compound and must be split, not forced into one of the two bins. “The second one” mid-list is a selection — neither a slot repair nor a new skill — and should hit the current list’s naming path. A polite “ok ok” overlapping readout may be a backchannel, not a command, and should not change state. If ASR hears “Saturday” as “don’t,” acoustics can fake a repair into an abandon — if a date value still follows, prefer repair.

Applying it

• On barge-in, record the slot or list item currently playing as the default repair target. Leave the current task unless a new-skill predicate or an explicit whole-order cancel appears.
• “No / change it to” plus a same-type new value: edit that slot, keep the others, do not reopen the skill.
• When the target is unclear, pin a closed question on the interruption point (“change the departure day, or drop this trip?”). Do not silently clear and do not keep reading.
• How to check: on the same confirmation, plant two barge-ins — “make it Saturday” and “play music first.” The first should change only the date and stay in the trip; the second should leave the trip. If both take the same path, the class has not been cut.

Related

• Same group: M3.09.1 Barge-in detection is capped by echo cancellation · M3.09.3 Ignored barge-in makes people raise their voice
• Nearby: M1.05 Topic Switching and Task Nesting · M1.06 Repair Strategies · C7.13 Voice Editing and Spoken Correction
• Search terms: barge-in as repair versus new request · other-repair · mid-prompt interruption