Audit and evidence

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

At a glance

• 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:

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.

Boundary

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:

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: the model behind these records.
• Stream and replay events: the replay contract in detail.
• Organization members and access: who can read the trail.