Stateful Systems
Build the system model around authoritative state.
Process
- Find the source of truth and its owner.
- Classify stored, derived, cached, projected, and displayed state.
- Map each meaningful transition with trigger, actor, precondition, write, publication, replay, and recovery.
- Define invariants and place each enforcement point at the boundary that owns it.
- Trace the relevant concurrent transitions, retries, ordering, freshness, and lifecycle restoration through representative scenarios.
- Shape commands around intent and reads around explicit freshness semantics.
- Derive proportionate boundary tests from the transitions, invariants, races, replay, and recovery in scope. Use the testing handoff below when generated exploration would strengthen a specific claim.
- Use
references/formal-modeling.md when critical or concurrent behavior remains ambiguous after the transition model.
When modeling stage cursors, publication, or metadata-driven replay, use forward implementation first to distinguish administrative records from authoritative controls.
Testing handoff
For each selected claim, identify the invariant, real implementation entry point, inputs or operation sequences to generate, expected result, and harness controls such as clock, scheduler, or failure injection. Record this in the existing plan or test description.
- Use property-testing for contracts spanning many values or transition sequences. Check invariants after meaningful operations; derive expected behavior from the contract or an independent reference model.
- Use fuzz-testing for malformed-input and parser boundaries. Identify expected rejection behavior and the crashes, unexpected errors, timeouts, or invariant violations that count as failures.
- Generated sequential operations establish sequence behavior. Claims about races require controlled interleavings or other concurrency evidence.
For implementation work, reuse the project's runner and generators, bound the exploration, and retain minimized failures with replay commands as regression evidence. Report the boundary exercised, run budget, outcome, and remaining limits. For planning work, provide this handoff without claiming execution. Finite exploration establishes only what was observed within the run.
Output
Return the authoritative state, transition graph, invariant set, boundary contracts, representative scenarios, and proof strategy. Include implementation and rollout shape when the request covers delivery.
Completion
Complete the model when every relevant transition has an owner and proof, every invariant has an enforcement point, and concurrency, freshness, replay, and recovery have evidence-backed behavior.
1---2name: stateful-systems3description: Model authority, transitions, concurrency, and recovery for a stateful design.4---56# Stateful Systems78Build the system model around **authoritative state**.910## Process11121. Find the source of truth and its owner.132. Classify stored, derived, cached, projected, and displayed state.143. Map each meaningful transition with trigger, actor, precondition, write, publication, replay, and recovery.154. Define invariants and place each enforcement point at the boundary that owns it.165. Trace the relevant concurrent transitions, retries, ordering, freshness, and lifecycle restoration through representative scenarios.176. Shape commands around intent and reads around explicit freshness semantics.187. Derive proportionate boundary tests from the transitions, invariants, races, replay, and recovery in scope. Use the testing handoff below when generated exploration would strengthen a specific claim.198. Use [`references/formal-modeling.md`](references/formal-modeling.md) when critical or concurrent behavior remains ambiguous after the transition model.2021When modeling stage cursors, publication, or metadata-driven replay, use [forward implementation first](../references/principles/forward-implementation-first.md) to distinguish administrative records from authoritative controls.2223## Testing handoff2425For each selected claim, identify the invariant, real implementation entry point, inputs or operation sequences to generate, expected result, and harness controls such as clock, scheduler, or failure injection. Record this in the existing plan or test description.2627- Use [property-testing](../property-testing/SKILL.md) for contracts spanning many values or transition sequences. Check invariants after meaningful operations; derive expected behavior from the contract or an independent reference model.28- Use [fuzz-testing](../fuzz-testing/SKILL.md) for malformed-input and parser boundaries. Identify expected rejection behavior and the crashes, unexpected errors, timeouts, or invariant violations that count as failures.29- Generated sequential operations establish sequence behavior. Claims about races require controlled interleavings or other concurrency evidence.3031For implementation work, reuse the project's runner and generators, bound the exploration, and retain minimized failures with replay commands as regression evidence. Report the boundary exercised, run budget, outcome, and remaining limits. For planning work, provide this handoff without claiming execution. Finite exploration establishes only what was observed within the run.3233## Output3435Return the authoritative state, transition graph, invariant set, boundary contracts, representative scenarios, and proof strategy. Include implementation and rollout shape when the request covers delivery.3637## Completion3839Complete the model when every relevant transition has an owner and proof, every invariant has an enforcement point, and concurrency, freshness, replay, and recovery have evidence-backed behavior.