Why derive a device's session state machine from a declarative transition table instead of hand-writing the transitions?

## A table is something you can analyse; branches are not A device session moves through a small number of states — offline, handshaking, streaming, throttled, closing — driven by events. Written by hand, that machine is a set of branches: each one correct in isolation, collectively describing a graph nobody can see. Written as a **declarative transition table** and generated into source, the graph is the artifact and the branches are its output. The whole argument turns on what can be done to data that cannot be done to control flow. Before a single line is emitted, the generator can walk the table and answer questions a compiler never asks about hand-written branches. ## What the generator can check before it emits 1. **Reachability.** Walk from the initial state across the declared transitions, transitively. Any state not visited is dead code you are about to generate. 2. **Totality.** For every reachable state, is there a rule — or an explicit default — for every event that can arrive? A missing pair is the failure that in hand-written code appears as an event silently ignored. 3. **Determinism.** Two rules for the same state-and-event pair are ambiguous. In hand-written branches the first match wins and nobody notices the second. 4. **Liveness of terminals.** A state with no outgoing transition is either a genuine terminal or a session that can never close, and the table makes you declare which. These checks are cheap because the input is small, structured data. They are effectively impossible over branch code, which is why hand-written machines accumulate exactly these four defects. ## What else the one table feeds Generating from a description is not only about the code: - **The diagram** in the design document can be emitted from the same table, so it cannot drift from behaviour. - **The test matrix** — every state-and-event pair — can be enumerated from the table, turning "did we test the throttled path?" into a count rather than a memory. - **Operational reporting** — the set of legal states, and the events that cause each move, can be published for whoever reads the logs. | Concern | Hand-written transitions | Derived from the table | |---|---|---| | Unreachable state | Invisible | Reported before emission | | Missing state-and-event pair | Silent ignore at run time | Reported before emission | | Two rules for one pair | First match wins quietly | Rejected as ambiguous | | Diagram agrees with code | By discipline | By construction | | Adding a state | Edit every branch site | Add a row, regenerate | ## Where this stops paying It is a genuine trade, not a free win: - **Guards and actions escape the notation.** Real transitions are conditional — move to throttled only if the rate exceeded a threshold — and conditions are code. They belong behind a hook the generated dispatch calls, which means the table describes the graph and hand-written code supplies the predicates. The checks above still hold over the graph; they do not extend into the guards. - **The notation grows.** Once the table wants conditions, timers, entry and exit actions and hierarchical states, you are designing a language, and every feature you add is one the generator must check and emit. - **Debugging goes through emitted dispatch.** A step-through lands in generated code, which is unfamiliar until people have read it once. - **Small machines do not need it.** Three states and four transitions are clearer as branches than as a table plus a generator, and the honest senior answer says where the line is. ## The point to land in an interview The reason to derive the machine is not that generated code is better code. It is that the **table is checkable and the branches are not**, and that one checked artifact can be projected into code, a diagram and a test enumeration that cannot disagree with each other. Say that, name two of the four checks, and name the guard problem as the cost — that is the complete answer.