How does Traverse handle errors?

Traverse produces typed errors at three distinct points in the execution pipeline. Each error type tells you exactly where the failure occurred, which condition failed, and what the state machine looked like at the time.

Precondition failures

Before the WASM binary runs, the runtime validates preconditions defined in the contract. If the input does not satisfy them, execution never starts. The error includes the capability name, the version, and which precondition failed with what input value. This is a hard stop — no partial execution happens.

Execution errors

If the WASM binary itself traps or returns an error, the runtime captures it as an execution error. The state machine moves to the error terminal state. The trace artifact records the input, the execution attempt, and the trap reason. You do not get a partial output.

Postcondition failures

After the WASM binary returns a result, the runtime validates postconditions. If the output does not satisfy them, the result is discarded and a postcondition error is returned to the caller. This is a safeguard against buggy implementations that return technically valid WASM output but violate the contract's guarantees.

What errors carry

• Capability name and version at the time of failure
• The specific condition that failed and the value that triggered it
• The state machine phase where the failure occurred
• The trace artifact up to the point of failure

Error handling for AI agents

When a capability fails via the MCP server, the error goes back to the agent as a structured MCP error response. The agent can read which precondition failed and adjust its inputs rather than retrying blindly. See how Traverse prevents AI agent errors for more.

See also: what happens when a capability fails.