Unreachable states and dead-end states are defects that the model detects mechanically

What it is

On a state transition model, two defect classes need no understanding of design intent: unreachable states—interface situations the model claims exist but that traversal can never reach from the initial state; and dead-end states—states with no transition out, or whose exits depend on ignored conditions. Graph algorithms compute both directly.

Why it happens

Unreachability is decided by traversal: run reachability from the initial state and whatever it never covers is unreachable; dead ends are states with an empty outgoing set, or a self-loop with no user-triggerable exit. The value of these checks is turning "can users get trapped?" and "does this situation actually exist?" from judgment calls into repeatable computation.

Studying it

The techniques come from formal verification's reachability and liveness analysis. Practice focuses on model fidelity: how many reported "defects" are false positives from implementation-model mismatch, and whether the abstracted dimensions—time, network failure—are exactly where a missing exit hides. Tooling extracts the state machine from implementation code and analyzes that, reducing hand-model bias.

Where it stops holding

Mechanical checking guarantees conclusions only inside the model: omitted conditions (permissions, network, time) distort "has an exit" verdicts, and "unreachable" may just mean the entry was never drawn. Every finding still needs human triage—dead code, missing entry, or stale documentation. Result correctness is out of scope: what happens inside states that are reachable and exitable is not the graph's business.

Applying it

• Run reachability and exit checks on critical-flow state machines before every merge, and put both into continuous integration.
• Triage each unreachable state: delete the dead code, add the entry, or record why the model keeps it.
• Check dead-end candidates for timeout, cancel, and back paths; a missing one is a defect to fix.
• Re-verify hand-drawn models against implementation-extracted ones and route the diff list to design and engineering jointly.

Related

• Same group: B4.17.1 Interaction can be modeled as repeated translation between the user's language and the system's, with loss possible at every step · B4.17.2 State transition diagrams can enumerate a UI's reachable states and illegal transitions · B4.17.3 Combinations of parallel controls explode the state count; exhaustive modeling only works locally · B4.17.4 A mode is one operation yielding different results in different states; mode errors can be located on the state graph
• Nearby: R2 Design Systems and Engineering Delivery · I1 State, Time, and Response
• Search terms: reachability analysis · dead state · liveness check