26 templates
State machine (FSM) templates
Native finite state machines, and the only engine here that decides whether the machine is one. A state machine's defects are facts about reachability and determinism, and neither has pixels: two arrows leaving a state on the same event with nothing to tell them apart is a machine and a coin toss, and it draws as two perfectly ordinary arrows. The engine reports nondeterministic branching, states nothing can reach, non-final states with no way out, a machine that can never terminate, and transitions naming states that were never declared — which every tool that draws what it is handed simply omits from the figure. Every arrow the document writes is drawn, and none is drawn through a box.
State machine — order lifecycle
Standard ecommerce order state diagram.
UML & SoftwareState machine — TCP connection
Simplified TCP connection state machine.
UML & SoftwareState machine — traffic light
Three-phase traffic-light state cycle.
UML & SoftwareState machine — auth session
Session auth state machine.
UML & SoftwareState machine — document publishing
Editorial doc state machine.
UML & SoftwareOrder Lifecycle — the Reference Machine
The one to copy. Every state is reachable from the declared initial state, every transition names states that exist, every fork carries a guard that distinguishes it, every non-final state has a way out, and a run can reach a final state. Retries and cancellations are ordinary cycles and the engine says nothing about them, because a loop is not a defect. Reports clean, and every one of the ten checks says what it covered.
Flow & ProcessTeaching Case — An Arrow to a State That Does Not Exist
One character changed: the transition out of `Paid` goes to `Shipd`. Every tool that draws what it is handed omits that arrow entirely — the renderer this engine replaces did `if (!a || !b) continue;` — so the figure showed a complete machine with one fewer edge, and nothing anywhere said an edge was missing. Here the arrow is drawn to a dashed box carrying the name that does not exist, and the reachability checks report a GAP rather than blaming the states the missing edge would have reached.
Flow & ProcessTeaching Case — A Machine and a Coin Toss
Two transitions leave `Review` on the same event and nothing tells them apart. The document does not say which one runs, so this is not a state machine: it is a state machine and a coin toss, and it draws as two perfectly ordinary arrows leaving one box. The engine also refuses the false positive next door — the fork out of `Draft` carries a guard on each branch, which makes it deterministic, and the engine says nothing about it.
Flow & ProcessTeaching Case — A State No Run Can Ever Be In
`Archived` is declared, labelled and drawn like every other state, and nothing enters it. No run of this machine can ever be in it — it is dead code with a box around it — and there is nothing in the picture to say so. The engine names it and dashes its outline, so the figure carries the finding rather than only the panel.
Flow & ProcessTeaching Case — A Deadlock Drawn as an Ordinary Box
`Held` is not marked final and has no transition out, so a run that arrives there stops and the machine has not finished. That is a deadlock, and it is drawn as a rounded box exactly like the states around it — the same shape, the same stroke, in the same row as the state that does finish. Note what the engine does NOT say: a final state IS reachable, by the other branch, so the machine can terminate and this is one stuck path rather than a machine that never ends.
Flow & ProcessTeaching Case — The Comment That Split the Figure From the Panel
Nothing in this document is wrong, and it is here because of what it used to do. There were two hand-written parsers for this notation — one for the drawing, one for the analysis panel — and the drawing's transition rule was anchored with a trailing `$` where the panel's was not. A transition ending in a comment was dropped from the FIGURE and kept in the PANEL, so the picture showed a machine with one fewer arrow than the text beside it described, both looking internally consistent, and nothing anywhere saying they were different machines. There is one parser now, and both read it. Reports clean.
Flow & ProcessTeaching Case — Two Boxes With One Name
`Cancelled` and `Void` are different states with the same label, so the figure prints one name twice. A reader cannot tell which arrow goes where, and a transition between the pair is indistinguishable from a self-transition on either of them — a defect that lives entirely in the drawing and cannot be seen by reading the source, which is where every reviewer looks.
Flow & ProcessTraffic Light (State Machine)
The cyclic states of a traffic light.
UML & SoftwareDocument Workflow (State Machine)
Draft, review, approve or reject a document.
Flow & ProcessVending Machine (State Machine)
Coin collection and dispensing states.
UML & SoftwareElevator (State Machine)
Movement and door states of a lift.
UML & SoftwareSubscription Lifecycle (State Machine)
Trial, active, past-due and cancelled states.
Business & StrategyGame Session (State Machine)
Menu, play, pause and game-over states.
UML & SoftwareConnection Lifecycle (State Machine)
Connect, drop and reconnect behaviour.
UML & SoftwareThermostat (State Machine)
Heating and cooling around a setpoint.
UML & SoftwarePedestrian Crossing (State Machine)
Signal states for a pelican crossing.
UML & SoftwarePackML unit machine — ISA-TR88.00.02 state model
The full seventeen-state PackML/OMAC unit machine — Stopped, Resetting, Idle, Starting, Execute, Holding, Held, Unholding, Suspending, Suspended, Unsuspending, Completing, Complete, Stopping, Aborting, Aborted, Clearing — with every SC transition and every Stop, Hold, Suspend, Reset, Clear and Abort command arrow, for the controls engineer writing or accepting PackML machine state code at FAT.
Flow & ProcessState machine — HTTP/2 stream lifecycle (RFC 9113 §5.1)
The normative HTTP/2 stream state machine from RFC 9113 §5.1 — idle, reserved local/remote, open, half-closed local/remote and closed — with all twenty transitions labelled by the frame that causes them (HEADERS, PUSH_PROMISE, END_STREAM, RST_STREAM) and by whether it is sent or received.
UML & SoftwareState machine — one SQS message, at-least-once delivery and the DLQ
State machine for a single Amazon SQS standard-queue message showing available, in flight, deleted, expired and moved-to-dead-letter-queue, with the visibility timeout, the ChangeMessageVisibility heartbeat, the four-day retention period and the maxReceiveCount guard that decides redelivery versus redrive.
UML & SoftwareError budget policy — freeze, waiver and window roll
The error budget policy of a 99.9%/30-day service as a finite state machine — healthy, watch, exhausted, time-boxed VP waiver and window roll — with the guard on every transition, for the SRE and product owner who have to sign it.
Operations & OpsTuring machine — binary successor
Three-state Turing machine transition diagram for incrementing a binary numeral, with arrows labelled read / write, move and the machine's reachability and determinism checked on the figure.
Mathematics