# Audit and evidence

Read the organization's audit trail, understand what the ledger proves, and find the execution record for a run.

Every governed action on Tanomis leaves a record. This guide shows where to read it and what each
record can and cannot prove.

- The **audit trail** is the organization's tamper-evident record of decisions: who did what,
  which policy allowed it, which approvals were given, which versions were enabled where.
- The **run record** is the authoritative outcome of each run, with its events replayable by id.
- The **execution trace** is the detailed record of what a run did, kept separately from the
  audit trail so evidence and debugging data can have different retention and access.

## Read the audit trail

Owners and admins can read the organization's trail from the Console or the CLI:

```bash title="Terminal"
tanomis org audit
tanomis org audit --limit 200
tanomis org audit --cursor "$NEXT_CURSOR"
```

Entries include membership and grant changes, invitations, enablement changes such as a rollout or
a `disable`, approval decisions, and delegation decisions. Each entry names the principal, the
tenant where relevant, the action, and the decision. Content such as prompts or tool payloads is
never in the trail; where content matters to a decision, the entry references it by hash.

## What the ledger proves

The trail is append-only, hash-chained, and signed per tenant. A valid chain demonstrates that the
record has not been altered or truncated since it was written. It is privacy-by-reference: an
auditor can verify that a decision was made about specific content without the ledger holding
that content.

The ledger is the platform's own record. It proves what Tanomis decided and recorded, not what
happened inside another system afterwards. To prove an external effect, read that system.

## Read a run's record

The run resource is the authoritative status of one unit of work, and its events can be replayed
by id at any time while history is retained:

```bash title="Terminal"
tanomis session get "$SESSION_ID"
curl "$TANOMIS_API/v1/sessions/$SESSION_ID/runs/$RUN_ID/events" \
  -H "Authorization: Bearer $TANOMIS_TOKEN" \
  -H "X-Organization-ID: $TANOMIS_ORG" \
  -H "X-Workspace-Tenant-ID: $TANOMIS_WORKSPACE" \
  -H "Accept: text/event-stream" \
  -H "Last-Event-ID: 0"
```

Replay starts after the id you give, so `Last-Event-ID: 0` reads a run from the beginning. Use the
run's terminal event and status together: a stream can end without a terminal frame, and the run
resource is what decides.

## Find the execution trace

Each run emits one execution trace: model calls, tool calls, timing, and content captured at the
level the tenant's capture policy allows (a reference, a redacted copy, or full content with
approval). The trace shares the run and session ids with the audit trail, so a decision in the
trail can be matched to the execution it was made about.

Trace access is tenant-scoped and gated by the tenant's policy at read time. Ask your
administrator which capture level your tenant runs and where its traces are served.

## Where to go next

- [Policy, approvals, and evidence](/concepts/governance): the model behind these records.
- [Stream and replay events](/guides/run/stream-and-replay-events): the replay contract in
  detail.
- [Organization members and access](/guides/manage/organization-members): who can read the trail.