A suspended task must keep its full mid-state

What it is

A pizza already has large and thick crust; toppings are half-asked when the user inserts an oven-preheat time. Coming back, if all that remains is “ordering pizza,” size and crust are empty — a blank ticket reopened. Suspended-task mid-state means what gets pushed is not the task name. It is filled slots, half-filled slots, and which question is next. Being able to return with a gutted state is, for the user, not having returned.

Why it happens

Mid-state is a checkpoint: which slots are grounded, which are still recognition hypotheses, which are empty, where the agenda points. A hang that stores only a skill ID can only re-enter at the skill’s door; turns already paid are void. Half-filled slots are the brittle ones: toppings may already hold “mushrooms” and still be waiting on “what else” — store only “toppings incomplete,” and mushrooms die; mark mushrooms complete and jump the agenda to confirm, and the unsaid part is cut off. The checkpoint also has to carry confidence: an item written at low confidence should still be marked unconfirmed on return, not promoted to fact by having been suspended once. If the world invalidates a slot during the insert (the kitchen’s last order time has passed), full save includes “these values were true at hang time”; on return, re-validate before asking onward.

Studying it

Run an interrupt-retention experiment: at a known filled set, insert a side task of fixed duration, then immediately probe each slot (“what crust”) and whether the next question is still at the interrupt point. Independents: number of filled slots, presence of a half-filled set-valued slot, insert duration, whether the insert is same-session. Dependents: slot-value survival, agenda-position drift, how much people re-fill after noticing loss.

On logs, compare the symmetric difference of the slot set before and after an insert. Main-task ID still there, large symmetric difference: the name lived, the checkpoint died. If the lab paints the form on a screen during the insert, the measure is visual store, not what the dialogue state machine kept.

Where it stops holding

A task with no grounded slot yet (just woken, just a skill name) is an almost empty checkpoint; losing it is cheap, and re-entering at the door is acceptable. Some slots must not be kept across a hang by law (payment tokens, one-time codes); full save excludes those, and return must re-fetch. On a shared device the checkpoint carries identity: the next person should not inherit a half-made pizza. Reading “full” as keep-the-audio-and-replay is unnecessary and unsafe — what to store is structured slots, not audio.

Applying it

• On hang, serialize: skill, grounded slots, half-filled sets, next agenda beat, per-slot confidence. On return, deserialize first, then speak.
• The resumption cue carries one or two filled items as a check (“large, thick crust, still adding toppings”). If the user says that’s wrong, repair the checkpoint before asking onward.
• External conditions that invalidate a slot during the insert are recomputed on resume; say so for items that died; do not silently submit old values.
• How to check: record size and crust, take one topping, insert an unrelated lookup, come back, ask “what crust,” and see whether the next line is still toppings. Crust gone, or the next line jumps to confirm: the checkpoint was not full.

Related

• Same group: M1.05.1 People insert new requests in the middle of a task · M1.05.2 After the insert, the original task has to resume · M1.05.3 Nesting depth needs a hard cap · M1.05.4 A topic switch and a correction are different intents · M1.05.6 Abandoning a task needs an explicit exit
• Nearby: M1.04 Context Retention · M2.07 Dialogue Flow and State Design · M2.03 Confirmation Strategies
• Search terms: suspended-task mid-state · slot checkpoint · dialogue snapshot