Three planes of audit
The platform's audit trail is not one log. It is three planes, each capturing what the others cannot:
- Database audit triggers. Every audited table records who changed what: the actor, the brand context, the action, and the before/after row state. This plane catches every write — including ones the application forgot to log.
- Application audit events. Business-meaningful events — sign-ins, gate decisions, exports, configuration changes — recorded with request context. This plane answers "what happened" in the vocabulary of the business, not of the schema.
- The hash-chained telemetry ledger. A tamper-evident chain over operational events: each entry commits to the one before it, so any later edit breaks the chain detectably. This plane is what lets a third party trust the first two.
Append-only by design
Audit records are insert-only. Nothing updates them, nothing deletes them — a correction is a new entry that references the old one. "Durably" is the whole point: the record must survive log rotation, staff turnover, and the end of any single vendor relationship, because the questions it answers arrive years later.
What always gets logged
- Identity events: sign-ins and sign-outs, multi-factor changes, role and tier changes, provisioning actions.
- Authorization failures: denied actions, recorded with the context that was refused — denials are evidence the boundary works.
- Gate decisions: every approval or refusal on a gated action, with the proposal, policy result, approver, and outcome — see approval gates.
- Privileged escapes: any use of a bypass path (for example a database role that skips row-level enforcement) requires a recorded reason at the highest severity; there is no quiet privileged route.
- Key rotations: signing-key changes in the identity layer, so token validity questions remain answerable historically.
Signed approvals for dangerous actions
Actions are classified on a danger scale — from reads, through scoped writes, up to financial, deployment, and irreversible operations. Above the irreversible threshold, an approval is not a click: the approver performs a step-up authentication, and the approval itself is cryptographically signed and stored with the action. The signature is the evidence artifact — proof that this specific person, on this specific device, authorized this specific action. (The exact danger-level thresholds are under counsel ratification and are deliberately not published here.)
What never enters the logs
An audit trail that leaks is worse than no trail. Never recorded: passwords or hashes, full tokens, private keys or seed material, government identity numbers, full payment card numbers, or full record payloads where the outcome suffices. Redaction is enforced at the logging layer across services — the rule is structural, not a reminder in a style guide.
Reconstruction is the test
Every property above exists to serve one operation: reconstruction. Counsel, an operator, or a reviewer should be able to rebuild a quarter, an incident, or a divested brand's history from the record — actor, context, policy, approval, outcome — without taking anyone's word for any step. The essay what "counsel-grade" actually means states the standard this model is built to meet.
Boundary
This page describes the evidence model, not any live record. Audit state, retention configuration, and the trail itself are authenticated-console surfaces.