State Machine Transition Table¶
State model — instantiates Deterministic Transition Contract
Enumerates, for every (current state, input) pair, the single next state the system must move to — turning the transition law into an exhaustive lookup with exactly one entry per cell.
The most direct way to make a transition determinate is to write it down completely. A State Machine Transition Table does exactly that: it lists the finite set of states the system can occupy, the finite set of inputs it can receive, and — in a grid — the single next state produced by each (state, input) pair. Its defining move is prospective exhaustive specification: it is the law itself, authored in advance, declaring what should happen for every reachable situation before any run occurs. Because each cell holds one and only one entry, determinism is not something the system hopes to achieve at runtime; it is guaranteed by construction, and the "same state plus same input yields the same successor" property is visible on the page. Undefined behavior becomes literally a blank cell you can spot and fill.
Example¶
A city intersection's traffic-signal controller must be provably determinate — a controller that "sometimes" turns two crossing directions green is a safety catastrophe. Its behavior is captured as a transition table. The states are the legal signal phases (North-South green, North-South yellow, all-red clearance, East-West green, …). The inputs are events: a phase timer expiring, a pedestrian button press, an emergency-vehicle preemption signal.
The table has one row per phase and one column per input, and every cell names exactly one next phase. In the North-South green row, "timer expires" → North-South yellow; "pedestrian button" → North-South green (latched, serviced at end of phase); "emergency preemption" → all-red clearance. Crucially, there is no cell anywhere whose entry is a state where two crossing directions are green — the unsafe successor is simply not writable in the table, so it cannot occur. When engineers review the controller, they read the grid and confirm every phase has a defined, single, safe successor for every input. A blank cell would jump out as an unhandled event to be specified before deployment, not discovered in traffic.
How it works¶
The table makes the transition law total and single-valued:
- Enumerate states and inputs. Fix the finite alphabet of situations the system can be in and events it can receive — the two axes of the grid.
- Fill every cell with one successor. For each (state, input), record the single next state; the law is the completed table, and "exactly one entry per cell" is the determinism guarantee made structural.[n1]
- Read the present state as a coordinate. A run consists of locating the current state and current input in the grid and moving to the named cell — the present-state snapshot is just the row you are on.
- Expose gaps as blanks. Any (state, input) with no defined successor is a visible empty cell, forcing unhandled cases to be designed rather than left to chance.
Tuning parameters¶
- State granularity — how finely the situation space is carved. Fine states capture more distinctions but can explode the table combinatorially; coarse states are compact but may hide a needed branch.
- Input alphabet completeness — how exhaustively events are enumerated. A complete alphabet leaves no undefined column; an incomplete one hides events that will arrive anyway.
- Default-cell policy — whether blank cells mean "error," "stay put," or "unreachable." An explicit default keeps the table total without enumerating every rare cell; a wrong default silently swallows real events.
- Output style — Moore (output attached to the state) versus Mealy (output attached to the transition). Moore is simpler to reason about; Mealy is more compact for input-dependent outputs.
- Guard richness — whether cells can carry conditions on cell entry. Guards keep the table small but push logic into the conditions, where a subtle overlap can reintroduce ambiguity.
When it helps, and when it misleads¶
Its strength is any system with a bounded, enumerable set of states and events where determinism and safety must be inspectable: controllers, protocol handlers, workflow engines, UI flows. The table makes the full behavior reviewable at a glance and makes unhandled cases physically visible.
It misleads when the real state space is large or continuous. Forcing a rich domain into a finite grid either explodes the table beyond comprehension or, worse, papers over important distinctions by collapsing genuinely different situations into one cell — determinism preserved, correctness lost. A tidy, single-valued table can also lull reviewers into trusting it while a guard condition quietly makes two cells applicable at once. The guarding discipline is to keep the state and input alphabets genuinely finite and disjoint — if the domain resists that, a lookup table is the wrong model — and to verify no guarded cells overlap, so "one entry per cell" is true in behavior and not just in layout.
How it implements the components¶
transition_law_set— the completed grid is the law: an explicit, total mapping from every (state, input) to its successor.present_state_snapshot— the current state is a row coordinate; the table defines state at exactly the granularity needed to select the next one.successor_uniqueness_criterion— one entry per cell structurally guarantees exactly one valid successor per situation.
It does not implement deterministic_replay_trace or law_version_lineage — recording what actually ran and tracking how the law changed over time are Transition Audit Log; the table is the prospective specification of the law, not the retrospective record of its execution.
Related¶
- Instantiates: Deterministic Transition Contract — supplies the explicit, single-valued transition law the contract is built around.
- Sibling mechanisms: Transition Audit Log · Golden Master Transition Test · Canonical Execution Order Runbook
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: State Machine Transition Table operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it enumerates, for every (current state, input) pair, the single next state the system must move to — turning the transition law into an exhaustive lookup with exactly one entry per cell.
Independent corroboration: The frozen evidence defines State Machine Transition Table as 'Enumerates, for every (current state, input) pair, the single next state the system must move to — turning the transition law into an exhaustive lookup with exactly one entry per cell', so its operative form is Representation, Specification & Plan.
Nearest alternative: Control, Automation & Runtime — State Machine Transition Table includes features of a live operational control that automatically routes, enforces, adapts, or responds during execution, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: An exhaustive current-state/input next-state table defines a deterministic automaton.
Related originating lineages:
- Engineering & Design — Controllers implement the table.
- Mathematics — Functions ensure one next state.
Review resolution: The blind reviewers agree that computer_science is the primary origin and differ only on alternate origin disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain single_lineage because the combined evidence shows one traceable formative lineage. The broader reach of specialized records portability separately from historical provenance; encyclopedia_synthesis=false preserves the affirmative synthesis judgment where either reviewer identified one.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A finite-state machine is a model with a finite set of states and a transition function mapping each (state, input) to a next state; when that function assigns exactly one successor per pair the machine is deterministic. The transition table is simply that function written out in full as a grid. ↩