Observability¶

Leaving a trace sufficient to inspect and reconstruct what happened, after the fact and live. The bar is "when something looks wrong, there's a log to point at — not a debugger session to reconstruct one."

How reyn handles it¶

The P6 audit-event log¶

Every state change reyn's own OS causes emits an audit-event to a JSONL stream (.reyn/events/<run_id>.jsonl) — one channel powering live debug output, reyn events replay, eval analytics, and (opt-in) OpenTelemetry export: OtelExporter (src/reyn/observability/otel_exporter.py, PR #2818) subscribes to this same P6 stream and maps each event to an OTLP span/metric/log, fail-open downstream — see reference: observability for the observability.otel.* config. There is no logger/tracer maintained SEPARATELY from this stream — every hook, including the OTel one, reads the same audit-events rather than instrumenting its own call sites. See Events for the full model, including the important distinction this lens has to keep sharp: audit-event (the observability trace) is a different thing from WAL-event (the crash-recovery/time-travel substrate) and hook-event (an external reactivity trigger) — conflating them is a real category error, not a stylistic nitpick (CLAUDE.md's Constitution section names all three explicitly).

`chain_id` — tracing a request across hops¶

A single top-level user submission mints a chain_id (uuid4 hex) that propagates unchanged across every agent-to-agent hop it produces. Cross-agent reconstruction of one logical request is grep <chain_id> over each agent's own events.jsonl — no centralized trace collector is needed because the identifier travels with the message itself.

`reyn events` replay¶

Replays a saved audit-event log to the console with the same rendering as a live run, without re-invoking the LLM — the log is the debugging tool, not a supplement to one. --filter TYPE narrows to one event kind (e.g. --filter permission_denied to jump straight to a denied op).

Live audit chips (inline CUI)¶

The inline CUI's status-chip bar (Agents / Cost / Model / Tools / MCP / Skills / Hooks / Pipes / Cron / Tasks) is this same audit trace surfaced live, inline, rather than only available via after-the-fact replay — the operator sees the same state the P6 log records, in real time.

Where it's still thin¶

Aggregation across runs is thin: there is no cross-run trend view or dashboard built on top of the audit-event log — each run's .jsonl file is a complete, self-contained record, but rolling them up into fleet-level observability is left to the operator's own tooling (the data is structured enough to feed into one). Payload-level trace inspection for LLM calls specifically (not just event kinds) is a separate, complementary surface — see docs/reference/dogfood-tracing.md.