A ledger you can verify, not a log you hope nobody edited
Every approval, execution, rollback, query, and role change is written to an append-only audit ledger. Events are hash-chained and periodically sealed with a Merkle root, so "who changed production?" has an answer you can prove rather than a row someone could have updated.
How the record is protected
Every event is written to a dedicated append-only table with a hash that includes the event before it, so editing a past row breaks the chain. The audit screen shows whether an event is already sealed or still pending a seal.
Batches of events are sealed. You can verify the whole ledger, and you can request an inclusion proof for a single event. MCP exposes VerifyAuditIntegrity for the same check from an assistant or script.
You set how long events are kept. The seals are kept even after the events themselves age out, so you can still prove that a period was sealed and unaltered after the records behind it are gone.
Where the answer lives
| Question | Answer from the ledger |
|---|---|
| Who approved this production change? | The approval event, user, timestamp, and environment bound to that change script. |
| Who read customer data? | Explorer queries are logged per user, including the statement, not only schema changes. |
| Has this record been tampered with? | Run integrity verification. A broken hash chain or missing seal is the finding. |
Ten-second cadence, sixty-second settle, proof per event
| Detail | Behaviour |
|---|---|
| Categories in the filter | Sign-in, Permissions, People, Environments, Connections, Change Scripts, Data access, Executors, Integrations, Billing, Audit log, Platform. |
| Change-script actions | Created, updated, deleted, approved, rejected, execution started/completed/failed, rollback, preflight evaluated, plus related flow, AI SQL, drift, and conversion events. |
| Sealing | Default interval 10 seconds, with a 60-second settle window before a batch is sealed. The Integrity column shows sealed or pending via the sealed-through sequence. |
| Without a signing key | Sealing needs a signing key. Until one is configured, events are still recorded in full and are sealed once the key is in place. Recording never waits on cryptography. |
| Verify | Verify the whole ledger or a date range from the product, the API, or an assistant over MCP, and request an inclusion proof for a single event. The audit screen also shows sealed or pending on every row. |
| Plan lock | Reading the trail back is included from the Scale plan. Recording happens on every plan, so nothing is lost if you upgrade later. |