M2.07.2no absorbing dialogue statedesignresearch

Every dialogue state needs a way out

Aliases: trap state · absorbing state · dialogue dead-end

What it is

Every node in the dialogue graph needs a way to leave that node, including when the user does not follow the script. If the “what time are you leaving?” node only accepts clock expressions, “not sure yet,” “uh…,” or silence leave the person there, re-prompted forever — an absorbing state, not “still collecting.” Having success / failure / exit as terminals for the whole task does not automatically give every intermediate prompt an exit.

Why it happens

Finite-state dialogue encodes “what we are asking now” as a node; a legal fill is one outgoing edge. Illegal input, silence, and off-topic replies with no edge are absorbing in the graph sense: whatever arrives, the machine stays. Designers hear “ask again” as service; they have made retry a self-loop with no cap. In speech the user cannot see which cell they are stuck in, only hear the same question in new clothes, so they raise their voice or give up.

An outgoing edge need not go to success. It can go to a narrower question, skip the slot, fail the task, or park. The event has to be consumed and the state has to change. Self-loops are legal only with a counter: after the third miss, leave. Treating “cancel” as the only trapdoor is not enough — people may never say that word; silence and “I don't know” need exits too.

Studying it

Encode the spec as a directed graph. For every non-terminal node, check whether four events have a successor: legal fill, silence/timeout, out-of-domain, “don't know / skip.” Dependents: nodes with no successor, nodes with unbounded self-loops, and the share of log sessions that stay on the same prompt for more than N turns.

Model checking can find absorbing states. A cheaper field probe is to inject, at each node, silence and one clearly unrelated utterance, and see whether the machine leaves or leaves after a finite retry. Task completion will not show this: completers never entered the trap.

Where it stops holding

A short spin waiting on a backend is a transient, not a prompt; its exit is timeout-to-failure, not a user utterance. Legally mandatory playback may treat barge-in as invalid and postpone the exit until the playback ends — say so, rather than pretend to listen. Quiz or PIN nodes that must be answered correctly exit by failing after a budgeted number of guesses, not by infinite guessing. One-shot stateless commands barely have intermediate nodes; the constraint bites on multi-turn slot filling.

Applying it

  • For each prompt node, fill a four-cell table: heard correctly → where; silence → where; not understood → where; user said don't-know → where. A missing cell is a missing edge; “ask again” is not a cell.
  • Self-loops need a count: after how many repeats the node is left, and whether leaving goes to failure, skip, or a human.
  • Repeating the identical wording does not tell the user the system is still alive. Changing the wording is not a new exit; an exit is a state change.
  • How to check: from every node, fire three probes (silence, out-of-domain, “skip”). Remaining in the node past the budgeted retries means the node is still absorbing.

Related

  • Same group: M2.07.1 Happy-path-only flows leave failure and walk-away unspecified · M2.07.3 A flowchart is not a substitute for real utterances · M2.07.4 Slot filling should accept scrambled order · M2.07.5 Cancel, restart, and help must work from every state · M2.07.6 State count grows past what you can test
  • Nearby: M1.07 Silence and timeouts · M1.11 Silence, timeouts and re-prompts · M2.02 Open and closed questions
  • Search terms: absorbing state · dialogue trap · state exit

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/M2.07.2