Audit trail

Documentation Index

Fetch the complete documentation index at: https://docs.usecompassai.com/llms.txt

Use this file to discover all available pages before exploring further.

The audit trail is what makes “glass box” more than a slogan. Every evaluation the agent runs — successful, rejected, or no-op — is written as a structured EvaluatorThought with all the inputs needed to replay it.

​

What gets recorded

{
  "thought_id": "th_01HXYZ...",
  "account": "0x7f3a...",
  "ticked_at": "2026-05-26T04:12:37.142Z",
  "trigger": {
    "type": "yield_update",
    "source": "<lending_protocol>:<l2_chain>",
    "old_apr_bps": 412,
    "new_apr_bps": 487
  },
  "load_state": {
    "positions": [...],
    "balances": {...},
    "policy_snapshot_hash": "0x..."
  },
  "fetch_yields": {
    "snapshot": [...]
  },
  "propose": {
    "outcome": "new_route",
    "candidate": {...}
  },
  "check_policy": {
    "outcome": "approved"
  },
  "emit": {
    "type": "signed_call",
    "tx_hash": "0x...",
    "gateway_intent_id": "gi_..."
  }
}

• The full inputs are captured, not just the decision. A reader can re-run the evaluator against load_state and fetch_yields and verify the same propose output.
• The trigger field shows why this tick ran at all. This is what closes the loop on the event-driven scheduler — every record explains what woke it up.
• The emit field links to the on-chain artifact when one exists. tx_hash for the smart account call, gateway_intent_id for the cross-chain settlement.

​

Five categories of records

​

What’s not in the trail

• LLM raw output for non-chat ticks. Most ticks don’t involve the LLM at all. The few that do (chat plans) record the prompt and the resulting structured Plan, but not the internal LLM tokens.
• Yield-source raw payloads. The fetch_yields snapshot stores normalized rates, not the underlying API responses. The adapter contracts and their version hashes are recorded, so a reader can reconstruct the raw payload if needed.
• User PII. The trail keys on the smart account address, not on any off-chain user identifier.

​

Where the trail lives

• Off-chain database, owned by the Compass backend. This is where the full EvaluatorThought records live, indexed for query.
• On-chain transactions. The emit field of any executed tick is a real on-chain transaction. These are independently verifiable on Arc and on the target chain regardless of what the off-chain database says.

​

Reading the trail

• Timeline. Reverse-chronological list of all five record categories, filterable by category and date.
• Per-position history. All ticks that touched a specific position, from the open through every rebalance and to the close.
• Rejected plans. Just the Tick — rejected and the rejected Chat plan records, with the failed rule name visible. Useful for understanding why the agent didn’t do something a user expected.

• The tx_hash on the appropriate block explorer.
• The gateway_intent_id on Circle’s intent viewer (when relevant).
• The full JSON for download.

​

Replaying a decision

1. Export a EvaluatorThought from the dashboard or query the trail API.
2. Identify the evaluator binary version from the record’s evaluator_version field.
3. Run that version of the evaluator against the recorded load_state and fetch_yields.
4. Verify the output matches the recorded propose and check_policy.

​

Retention and access

• Retention. Records are kept indefinitely during the testnet phase. Retention policy for mainnet is not yet finalized.
• Access. The trail for an account is visible to the owner of that account via the dashboard. There is no admin view that lets the Compass team browse other users’ trails.
• Export. Owners can download their full account trail as JSON from the dashboard. Useful for tax reporting, auditing, or simply keeping a copy outside Compass.

​

Next steps