New-turn slots need overwrite versus overlay

What it is

“Remind me at three to call mom.” The next line, “make it four,” overwrites the time. “And also text dad” adds a second object. “Make it daily” overlays an attribute on the same object. When a new turn mentions a slot already filled, dialogue-state update has three operators. Last-write-wins on every slot is not one of them. Overwrite versus overlay is about the type of this write, not about whether context still exists.

Why it happens

The same slot name appearing again is often already marked for an algorithm. “Actually / no / change it to” marks replacement: the old value is retracted. “Also / add another / and also” marks a new entity. “While you’re at it / also” sometimes adds a field on the same entity. Ontology constrains the rest: a navigation destination is usually singleton, so add is illegal; a shopping list defaults to add; an alarm time might be a retiming or a second alarm.

The costs of the wrong operator are asymmetric. Treat “also” as overwrite and mom’s reminder vanishes. Treat “make it four” as overlay and the three-o’clock one remains; the user gets two calls. This is replace / merge / add-entity on dialogue state. It is not binding the wrong referent — the object may already be right; the update operator is wrong. A bare restatement (“four”) is the most ambiguous. Discount it by slot cardinality (can this slot hold two values), not by a blanket last-write-wins.

Studying it

Build discourse-marker minimal pairs: same slot name, same prior state, only the marker in the follow-up changes (“change it to four / also book four / four”). Ask annotators for the intended state operation: replace, merge a field, or add an entity. Align entity count and slot values after the current DST runs. The dependent measure is update-type error, not referent accuracy.

Stratify by slot cardinality: ontology-singleton slots, multi-value lists, and singletons that can become a list (a second alarm). Do not, in this study, measure how long the prior state remains valid — it is assumed still live.

Where it stops holding

In legal or payment flows, “switch to the other card” must overwrite and leave an audit; overlay would become two charges. If the user edited a slot on screen and then spoke about a different slot, a voice-side overwrite may hit a stale spoken copy. A multi-intent line that both changes and adds (“move the time to four, and add one for dad”) has to split into two updates; they cannot share an operator. A pronunciation repair (“four, not three”) looks like overwrite and is really a recognition fix; treat repair first.

Applying it

• Classify follow-ups as replace, merge, or add from markers plus slot cardinality. When a singleton refuses add, say so (“there can only be one destination — change it to that one?”).
• When the operator is unclear, ask about the operation, not the slot name: “change it to four, or set another one at four?”
• After the update, read back entity count and the key slot. Overwrite should drop an old value; add should grow the object count.
• Keep at least two regression cases each: retiming, adding a second item, overlaying recurrence on the same item. Inspect state, not only the NLU label.

Related

• Same group: M1.09.1 Referent candidates come from talk, screen, and the room · M1.09.2 Subject-dropped fragments need completing from the last turn
• Nearby: M1.04 Context Retention · M2.13 Multi-Intent and Compound Commands · M2.07 Dialogue flow and state design
• Search terms: slot overwrite versus overlay · DST update · replace or add