A condition is not a workflow
A rule answers a local question:
if error_rate > 0.05:
severity = "high"
That is useful, but it does not tell us whether an incident is new, acknowledged, being investigated, waiting for approval, or resolved. That is state.
State is the durable record of where a piece of work is in its lifecycle, plus the facts the system needs to decide what may happen next. It is not simply a variable that exists while one function runs. Good state survives a retry, a restart and a hand-off to a human.
Model the work honestly
The Workbench now makes this small state machine visible:
new → triaged → investigating → waiting-for-human → resolved
↓
closed-as-noise
Each transition needs a reason. The Workbench refuses transitions that do not make sense: you cannot resolve an incident that was never investigated, and you cannot investigate one that has been closed.
The deterministic checkpoint keeps the incident’s state in the scenario, shows the valid next states, and records a transition in the event timeline. The route is still a decision about the evidence; state is the workflow’s memory of where it is.
Why state is a gift
State gives us three things that are hard to get back later:
- A shared understanding of what is happening now.
- A safe place to resume after a failure.
- A record of why the system did not take some other path.
This becomes important when we add a model. A model call is not the state of the investigation. It is one event inside it.
Try it
Open Checkout regression. It starts in investigating, so the Workbench offers only waiting-for-human and resolved as valid next states. Choose Waiting for human, record the transition, and inspect the event timeline.
Then choose Duplicate alert. It begins as new, so the only valid move is triaged. The selector is not a convenience feature. It is the workflow refusing to tell a story it cannot support.
Keep this with you
If a piece of work takes more than one step, write down its states before you ask an LLM to navigate them.