Happy-path-only flows leave failure and walk-away unspecified

What it is

A dialogue skill has to end, and there are only three endings: it worked, it cannot work, and the person left mid-way. Drawing “a car was dispatched” does not finish the flow — no cars nearby, payment declined, hang-up after the destination was given are equally real terminals. The claim is whether the whole task has three closings, not whether a single prompt node has an escape, and not how a failure is worded.

Why it happens

Designers draw backward from the system's goal. The chain that reaches the goal is the clearest, so the diagram keeps only success. Failure comes from the world (stock, network, policy); mid-course exit comes from the user (impatience, interruption, change of mind). Neither sits in the mental model of “how the task is done,” so neither enters the diagram. In speech they still occupy a turn: the system must speak or close, or the session hangs in mid-air — the user thinks it is still running, the backend thinks it is finished.

The next move differs by terminal. Success delivers the result audibly. Failure names a class of reason and whether an alternative exists. Exit must void or briefly park the slots already collected, not keep prompting an empty room. Collapsing the last two into a single “incomplete” bucket means acceptance tests only the success chain; live logs then land off the diagram.

Studying it

Archive logs of one skill by terminal class, not by a binary of task success. Independent variable: whether the spec writes all three terminals. Dependent variables: share of sessions that end in an unspecified terminal, whether people retry the skill after failure, which turn hang-ups occur on.

Labs can inject faults: in Wizard-of-Oz or a live skill, script “no result” and “API failure,” and stop answering halfway through slot filling. Watch whether the system produces a recognizable failure close or repeats a success-path prompt. Completion rate is the wrong summary: it treats exit as noise, which is exactly the third terminal to cover.

Where it stops holding

On a one-shot command (a ten-minute timer) failure and exit can collapse into the same “didn't catch that”; the three terminals still exist, just squeezed into one or two turns — they do not each need a long chain. Open chit-chat has no single success criterion; forcing three terminals fabricates a task. Mandated disclosures that must be read through postpone exit until the disclosure ends. Treating a nested side request as “mid-course exit” is a different phenomenon: that is a task being parked, not this task being abandoned.

Applying it

• Write three terminal utterances per skill: what success says, what cannot-complete says, what leaving says. Split cannot-complete once more: world cause (no cars) versus system cause (didn't hear). Do not share “something went wrong.”
• Add two columns to acceptance: force one failure; force silence in the middle. If either still reaches a success prompt or loops, coverage is incomplete.
• Do not silently clear slots on exit; at least acknowledge the stop, and decide whether filled slots are dropped or kept.
• How to check: label a week of logs as success / failure / exit / off-diagram. If off-diagram is more than a small slice, add terminals rather than polishing the success chain.

Related

• Same group: M2.07.2 Every dialogue state needs a way out · 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.05 Topic switching and task nesting · M1.12 Opening and closing a dialogue · M2.04 Error-recovery wording
• Search terms: three-terminal dialogue coverage · happy path · task abandonment