Skip to main content

​
Traces and Export

Every session starts with a root span. Model requests and tool runs create child spans, which gives the platform a structured trace tree rather than a flat event log. The best trace is readable on its own. Someone should be able to tell what the app tried to do, what was blocked, what was allowed, and where the time or cost went without digging through unrelated logs.

​
Event types you will see

  • session.started
  • request.started
  • request.allowed
  • request.blocked
  • estimate.reserved
  • provider.response
  • spend.committed
  • tool.started
  • tool.completed
  • guardrail.violation
  • session.closed

​
Why export matters

Exported traces become the bridge into platform workflows:
  1. Inspect prompts, responses, spend, and violations on the trace page.
  2. Export strong traces into project datasets.
  3. Review those rows in manual eval runs.

​
What to preserve

  • Session metadata that explains who or what the run was for
  • Prompt and response payloads when your retention policy allows it
  • Budget reservations and spend reconciliation
  • Tool execution decisions and guardrail outcomes
  • Enough span hierarchy to make the sequence easy to follow later
Captar’s first product slice is built around traces that are useful enough to become dataset rows and manual review inputs.