# Traces and content classes

Match a ledger decision to the execution it was made about, and understand which content class you are allowed to see when you do.

The ledger says what was decided; the execution trace says what the agent did. They are kept apart
on purpose and joined by the run and session identifiers, so an auditor can move from a decision
to the execution behind it, at the content level the tenant permits.

- Every ledger entry that belongs to a run carries the run and session ids; every trace span
  carries the same.
- Content in a trace is classified: `reference`, `redacted`, or `full`. The class you are served
  is decided at read time from the tenant's current policy.
- A ledger entry references trace content by hash, so a decision can be checked against the
  content without the ledger holding it.

## From a decision to a trace

1. In Assurance, open the decision and choose its trace link. Traces live in the Quality section's
   Traces tab, where evals grade them, and the link opens the run's trace there.
2. To browse instead, open Quality, then Traces, and look the run up by session or trace id.
3. The span for the decided action, a tool call or a model call, shows the decision's identifiers
   beside the captured content.

The Sessions screen offers the same path from the other side: a session's evidence panel lists its
runs' decisions and links into the trace.

## Content classes

| Class | What you see | Who decides |
|---|---|---|
| `reference` | Structure and hashes: which calls happened, in what order, with what outcome | Tenant capture policy |
| `redacted` | Bodies with sensitive spans removed by tenant redaction rules | Tenant capture policy |
| `full` | Complete bodies | Tenant capture policy, and an approval to serve |

The class is decided inside the sandbox when the content is captured, from the tenant's policy,
and rechecked when you read. The server derives the class from what it captured, never from a
label the agent wrote, so an agent cannot promote content into a class it is not allowed to be.

## Matching content by hash

A ledger entry about content carries the content's hash. If you hold the content, from a `full`
trace or from your own system, hash it and compare. This is how the ledger stays free of prompt
and payload bodies while still binding decisions to exact content.

## Where to go next

- [Capture execution traces](/guides/evaluate/capture-traces): what a trace contains.
- [Audit and evidence](/guides/audit/audit-and-evidence)
- [Data handling and retention](/guides/govern/data-handling): planned page on storage and
  retention.