Validation-first development

Define state machines from requirements before implementation. Specifications say what the system MUST do. Encode compile-time properties in types first, then layer state machine modeling for properties types cannot express.

Modern insight (2025): State machines exist on a spectrum from runtime enums to compile-time typestates. Use the strongest mechanism available. XState v5 introduces actor model semantics -- state machines are now first-class concurrent entities, not just enum switches.

See approaches for language-specific state machine mechanisms. See examples for brief state machine patterns per language. See formal-tools for specification and model checking tools.

---

State Machine Taxonomy (decision guidance)

Level	Mechanism	Strength	Use When
Typestate (compile-time)	Generic type params, phantom data	Invalid transitions unrepresentable	Protocol APIs, builder patterns, Rust FFI
Statecharts (hierarchical)	Nested states, parallel regions	Complex workflows, entry/exit	Game state, multi-modal UI, XState
Flat FSM (runtime)	Enum + match/switch	Simple, auditable	Order lifecycle, connection mgmt
Actor model	Independent entities, message passing	Concurrent state	Distributed systems, Erlang/Elixir, XState v5

Default choice: Use the strongest mechanism the language supports. Typestate in Rust, sealed classes in Kotlin, discriminated unions in TypeScript.

Validation Levels

Type system (strongest) > State machine > Contract > Runtime check (weakest)

---

When to Apply

• Protocol implementations (network, API, auth flows)
• Workflow engines (approval chains, CI/CD pipelines)
• Concurrent/distributed systems (coordination state)
• Order lifecycle (e-commerce, payments, shipping)
• Connection/session management
• Actor systems with message-driven state
• Event sourcing aggregates (command validation against current state)

When NOT to Apply

• Stateless REST endpoints
• Pure data transformations (map/filter/reduce)
• Simple CRUD without lifecycle
• Configuration parsing
• Batch processing without state

---

Anti-patterns

• Boolean soup:

  { isLoading: true, isError: true, data: X }

  -- contradictory states representable. Use discriminated unions instead.
• Stringly-typed states:

  state: "pending"

  with no exhaustiveness check
• Partial transition coverage: Some transitions undefined -- runtime "impossible" states
• Split-brain: State and behavior in separate modules -- changes require cross-module updates
• Invariants at boundaries only: Check invariants at every transition, not just entry/exit
• Implicit transitions: State changes scattered across codebase -- impossible to audit
• State explosion without hierarchy: Flat FSM with 50+ states -- use statecharts (nested states)

---

Pseudocode Template

STATE MACHINE: <Name>
  STATES: S1 | S2 | S3
  VARIABLES: var1: type, var2: type
  INIT: var1 = val, state = S1
  ACTION name(args): PRE: guard -> POST: new_state, effects
  INVARIANT: condition_that_always_holds

Event Sourcing Integration

When state machines guard event-sourced aggregates:

1. Command arrives -> validate against current aggregate state machine
2. If transition valid -> emit immutable event
3. State rebuilt from event replay
4. Invalid transitions rejected before events created -- impossible to corrupt event log

---

Workflow (language-neutral)

1. PLAN -- Identify states, variables, actions, invariants from requirements. Draw state diagram.
2. CREATE -- Define state machine spec using pseudocode template. Choose mechanism level (typestate/FSM/actor).
3. VERIFY -- Type-check, confirm exhaustive matching on all states, validate invariants hold at every transition.
4. IMPLEMENT -- Target code mirrors spec. One state type, one transition function, one invariant check per concern.

---

Constitutional Rules (Non-Negotiable)

1. CREATE First: Define state machine specification from plan
2. Invariants Must Hold: All invariants verified at every transition
3. Actions Must Type: All actions type-check with exhaustive matching
4. Implementation Follows Spec: Target code mirrors specification structure

Validation Gates

Gate	Pass Criteria	Blocking
Typecheck	No errors; exhaustive match where language enforces it	Yes
Invariants	All invariant assertions pass after each action	Yes
Tests	All state transition tests pass	If present

Exit Codes

Code	Meaning
0	Specification verified, ready for implementation
11	Checker not available
12	Syntax/type errors in specification
13	Invariant violation detected
14	Specification tests failed
15	Implementation incomplete