validation-firstlisted

# 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](references/approaches.md) for language-specific state machine mechanisms. See [examples](references/examples.md) for brief state machine patterns per language. See [formal-tools](references/formal-tools.md) 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