What is the Traverse execution state machine?
Traverse models every request as a state machine. Each step in the execution pipeline is a named state. Every state transition is logged to the trace artifact. If anything fails, the machine moves to error and records the reason.
The states in order
| State | What happens |
|---|---|
| idle | No active request. The runtime is waiting. |
| loading_registry | The capability bundle is being parsed and loaded into the registry. |
| ready | The registry is loaded. The runtime can accept requests. |
| discovering | The registry is searched for capabilities that match the requested goal and placement target. |
| evaluating_constraints | Preconditions are checked on each candidate. Sandbox constraints are verified against the requested environment. |
| selecting | The best matching capability is chosen from the candidates that passed constraint evaluation. |
| executing | The WASM binary is loaded into the sandbox. Inputs are validated. The entrypoint is called. Outputs are validated. |
| emitting_events | Output events declared in the capability contract are published. |
| completed | Terminal success state. Trace artifact is written. |
| error | Terminal failure state. The reason and the failing state are recorded in the trace artifact. |
How errors propagate
Any state can transition to error. The transition carries the name of the state that failed and the reason. This means you can look at a trace artifact and immediately know: the machine failed in evaluating_constraints because precondition X returned false.
Why a state machine
A state machine makes execution auditable by construction. There is no implicit control flow. Every path through the system is a sequence of named states. You can test each state transition in isolation. You can reproduce any execution from its trace artifact.
This design also makes error handling straightforward. You do not need to reason about where in a complex call stack a failure occurred. The state name tells you.