---
id: "prereq-system-state-machines"
type: "prerequisite"
source_timestamps: ["00:10:52"]
tags: ["computer-science"]
related: ["concept-workflow-state-separation"]
reason: "Necessary for implementing explicit workflow states that survive system crashes."
sources: ["s46-anthropic-25b-leak"]
sourceVaultSlug: "s46-anthropic-25b-leak"
originDay: 46
---
# State Machine Concepts

## Why This Matters
Understanding how to separate [[concept-workflow-state-separation|workflow state]] from conversational history requires basic familiarity with **state machines** and how to model long-running processes.

## Required Knowledge
- A **state** is a named condition the system can be in (e.g., `planned`, `awaiting approval`, `executing`).
- A **transition** moves the system between states based on events.
- **Side effects** are typically tied to transitions, not to states themselves.
- A well-modeled state machine lets you answer *"is it safe to retry this transition?"* deterministically.

## Why It's a Prerequisite
Without state-machine fluency, the architectural argument for separating workflow state from chat history reads as redundant. With it, the argument becomes obvious: chat transcripts can't tell you which transitions have already fired.