Trace Events Reference

Trace events are append-only runtime contract data. They prove what the runtime observed, proposed, verified, executed, denied, committed, and replayed.

Trace event identity

Each trace event carries:

• trace_event_id;
• run_id;
• monotonic sequence within the run;
• timestamp;
• event type and payload;
• identity context such as tenant, agent, tick, action, state, message, work order, approval, node, or instance IDs where relevant;
• integrity metadata where enabled.

The older name trace_id may appear in some development-era material as a compatibility alias. Public docs use trace_event_id.

Required tick events

A complete successful tick records:

1. tick.started
2. percepts.received
3. state.loaded
4. policy.invoked
5. policy.completed
6. actions.proposed
7. constraints.evaluated
8. verification.started
9. verification.completed
10. action.executed, action.denied, action.failed, action.needs_approval, or action.needs_intervention
11. outcome.recorded
12. state.committed
13. tick.completed

Additional events cover messages, work orders, approvals, circuit breakers, policy state, state handoff, trace sync, replay, and physical/edge safety facts where those primitives are used.

Failure and denial events

Denials and failures are first-class trace facts. They should include reason codes and enough identity scope to explain why an action, message, work order, state import, approval, or replay request did not proceed.

Replay relationship

Replay uses trace events as evidence. It validates run scope, ordering, identity, and integrity before reconstructing behavior. Replay does not create new runtime authority from historical trace data.