The audit trail

The audit trail is the record of everything an agent tried to do. Every query produces a series of append-only events, and the decisive ones are written before the query runs. Denials are recorded just like executions, so the trail is a complete history of what the agent attempted, not just what it managed to run.

​

The five event types

A single query is identified by a query_id that groups all of its events. Most queries produce three or four: A denied query produces ATTEMPTED and DECIDED, then stops — there’s no EXECUTED event because the query never ran.

​

The guarantee: audited before executed

The engine writes the ATTEMPTED and DECIDED events before the query touches the database — the ordering that makes the audit write a precondition for execution. For the trail, that ordering buys two things:

• Nothing reaches your database unaudited. There is no path where a query executes but its attempt and decision aren’t on record.
• Post-execution events are best-effort. The EXECUTED / FAILED events are logged after the fact and don’t block — the pre-execution rows already prove intent.

​

What a row carries

Every event is one row. The columns answer who, what, when, and how it was decided: The agent_intent field is what turns the trail from “what ran” into “why.”

​

Read it

The schema is identical in both deployments — Cloud mirrors the open-source shape column-for-column — only the storage and how you read it differ.

​

Next steps