What this is, and who it is for
The platform audit ledger is the control plane's own record: every action of a Super-Admin, and every refused sign-in of a known one. It is separate from the data plane's audit trail, which belongs to the organizations. It is append-only and hash-chained: each entry stores the hash of the one before, so any insertion, removal or alteration is detectable. This page is how to read it.
Where to find it
Platform Audit in the console menu (Every Super-Admin action, append-only and hash-chained. Read-only by design.).
- Narrows the ledger to an action or a group of actions, for example org. or admin.
What you can do
- Read. Each row shows When (the date and time and how long ago), Action (a color for the group: organization actions, administrator actions, suspensions and closures), Actor (the administrator's address, or service key when the act was made with the static service key, which carries no individual identity), Target (the kind and the first characters of its id) and Detail (the first three facts of the entry, such as
reason=…). - Filter by action. Filter by action matches the start of the action name:
org.shows every organization action,org.suspendedonly suspensions,admin.every administrator action. The list loads 50 at a time, newest first, and Load more continues.
The same filters exist in the API for one target (targetType, targetId), so one organization's history can be read through it.
Every option
What the ledger holds
| Action | Written when |
|---|---|
admin.bootstrapped | The first Super-Admin of a deployment was created from the command line |
admin.invited, admin.suspended, admin.restored | A Super-Admin was invited, suspended or restored |
admin.login | A Super-Admin signed in |
admin.login_refused | A known Super-Admin was refused: suspended, wrong code, attempts used up (with the reason). Addresses nobody holds leave nothing, so nobody can grow the ledger by typing |
org.provisioned, org.data_plane_synced, org.data_plane_sync_failed | An organization was created, pushed to the data plane, or the push failed |
org.updated | An organization's details were corrected (both values, and the reason) |
org.suspended, org.restored, org.closed | An organization's status changed (the reason, and whether the data plane applied it) |
org.admin_invitation_resent | The first administrator's invitation was sent again |
entitlement.set | A feature switch was changed |
How it is protected
Each entry is written in the same transaction as the action it records, so neither can land without the other. Each entry's hash covers the previous entry's hash and its own canonical content (the action, the actor, the target, the facts and the time the application gave it), and the database stamps its own recording time, which the application cannot set. Two database triggers, which stay on even when a session switches triggers off, refuse an UPDATE or DELETE of an entry and a TRUNCATE of the table, and the runtime database role holds only read and append on it: a trigger does not bind a role that owns the table, so the application connects as a role that does not own it, and in production the server refuses to start unless that holds. Someone who owns the database can still drop a trigger, but that is a visible change to the schema rather than a setting, and an operator with access to the database host as its owner is covered by the hosting controls (Security and hosting).
What the system records
Reading the ledger leaves no entry of its own.
What you cannot do, and why
- Edit or delete an entry. The database refuses it.
- Verify the chain from the console. There is no verify button on the platform ledger; the data plane's trail has one (Review organization access and audit). The hashes are shown in the API's answer for an external check.
- Read an organization's own audit trail. That belongs to the organization.
Compliance Q&A
Partly. Every Super-Admin action is written in the transaction of the action, chained by hash, and protected by triggers and by a runtime role that can only read and append.
Limits: the console does not verify the chain; verification is a check an operator makes against the hashes. The ledger is not anchored outside the database. The step that appends an entry reads the latest hash without locking it, so two Super-Admin actions at the very same moment could both chain to the same predecessor; at the volume of platform administration this is unlikely, and it would show as a fork when the chain is checked.
Evidence: control plane infrastructure/audit.ts (hash chain, same transaction)migrations (trigger blocks UPDATE and DELETEruntime role has SELECT and INSERT only)simulation of 20 Oct 2026, step 1 (db proof)
Related
The platform console · Signing in and platform administrators · Review the audit trail · Audit trail and evidence