University of Michigan - Ann Arbor

StateM strictly distinguishes between two architectural layers:

- **Runtime**: Supplies the generic, domain-agnostic mechanics for state persistence, transition validation, hook execution, history logging, and crash recovery.
- **Control Profile**: Encoded in a YAML runbook, this layer specifies the concrete phase states, prompts, checks, repair paths, and procedural practices required for a particular workflow or task family.

This separation enables the underlying runtime infrastructure to remain reusable across different agents, models, and environments, while procedural knowledge accumulates modularly within the versioned control profile.

Separation of Generic Runtime and Control Profile

Which set of responsibilities is handled directly by the generic StateM Runtime layer rather than the Control Profile?

The StateM runtime infrastructure must be re-engineered or modified whenever an agent is deployed across different models or environments.

In what specific artifact format is the StateM Control Profile encoded?

Formally, a StateM runbook is defined as a tuple:

$$\mathcal{B} = (\mathcal{S}, s_0, \mathcal{S}_T, \mathcal{E}, \Phi)$$

where:
- $\mathcal{S}$ denotes the finite set of phase-level states,
- $s_0 \in \mathcal{S}$ is the designated initial state,
- $\mathcal{S}_T \subseteq \mathcal{S}$ is the set of terminal states denoting completed execution,
- $\mathcal{E} \subseteq \mathcal{S} \times \mathcal{S}$ is the set of directed, permitted transitions between states, and
- $\Phi(s)$ is the state specification mapping each state $s \in \mathcal{S}$ to its phase-local configuration, including the phase prompt, entry and exit hooks (`in_hook`, `out_hook`), transfer checks (`before_transfer`), and references to state-local artifacts.

Formal StateM Runbook Specification

Explain the structural separation between the Runtime and the Control Profile in StateM, and describe the benefits this architectural division provides.

Learn Before

Related