Skip to main content

The audit planes

The platform does not have "an audit log." It has a shared chain mechanism instantiated per domain, and several distinct kinds of audit that answer different questions.

Understanding the partitioning is what makes the record usable, because it is also what stops one compromised or overfull store from taking the whole account of what happened with it.

Audit is partitioned by domain​

Each of the cell's logical databases carries its own audit store: system, directory, catalog, storage, compute, messages and data each have one.

This is not filing convenience. A workspace's record is a separate chain rather than a filtered view of a shared log, which means one domain's audit cannot be reconstructed from another's, and a reader scoped to one domain is structurally scoped rather than query-scoped.

Underneath them all sits one shared chain mechanism: an appender, chain heads, signing, checkpointing and export. So the guarantees are uniform even though the stores are not shared.

Three kinds of audit, per domain​

KindThe question it answers
Read audit trailWho looked? Observations recorded with stable identifiers, so a retry is idempotent rather than double-counted
Lifecycle auditWhat happened to this object over its life? Provision, change, suspend, decommission
Deletion auditWhat was removed, by whom, and under what authority?

Reads being audited at all is the unusual one. Most platforms audit writes and treat reads as too voluminous to record, which means the question a regulator actually asks, who saw this, has no answer. A single read-audit chokepoint records observations into per-database read-audit trails.

Deletion is a first-class audited event​

Deletion gets its own plane, separate from lifecycle audit, because it is the event most likely to be the subject of a dispute.

Every domain that can delete has a deletion audit store: system, directory, catalog, storage, compute and messaging each carry one. Alongside them, the system domain keeps deletion tombstones.

The distinction matters: the deletion audit records the act, and the tombstone records that the thing existed and is gone. A reader encountering a tombstone can therefore distinguish deleted from never present, which an absence cannot do.

Tombstones are garbage-collected deliberately, including a conflict-free replicated tombstone sweep, rather than accumulating without bound or being dropped the moment they are inconvenient.

Soft delete is enforced, not conventional​

This is the part that makes the rest trustworthy, and it is enforced one layer below where a developer could forget.

Rows are soft-deleted by default: a delete sets is_deleted and a deletion timestamp, and ordinary reads filter deleted rows out. What makes it reliable is that the data-access layer refuses to let a writer set those fields by hand. A row handed in carrying delete fields raises, with a message directing the caller to the proper soft-delete, hard-delete and restore operations.

So "did someone bypass the soft-delete convention" is not a question you have to audit for. It is not representable.

Three consequences follow:

  • Restore is a real operation, because the row is still there.
  • A hard delete is an explicit, separate act, not the default path.
  • Deletion audit and tombstones have something to point at, rather than describing a row nobody can examine.

Directory audit specifically​

The directory, holding every entity, gets the full set: a read audit trail, a lifecycle audit, a deletion audit, and a separate federation audit for identity arriving from an external provider, with actor attribution.

That last one closes a gap that is easy to miss. When a user is provisioned by an external identity provider over SCIM, or authenticates through a federated login, the question "who created this account" has an answer that is not "the platform." Federation audit records the external actor.

System audit and the estate record​

Above the per-domain planes, the system domain carries the estate's own record: cells, service groups, fabric leases, licensing and metering all audit into it, and each cell emits a signed effective-configuration attestation on every reconcile tick, hash-chained into the audit.

That attestation stream is what makes fleet governance symmetric rather than write-only: the node does not only distribute policy, it observes what every cell actually applied.

The properties that hold across all of them​

  • Hash-chained, with a verify endpoint on the workspace activity ledger.
  • Gaps are counted. When an append fails, the gap is written as a first-class event, so a verifier distinguishes a known append failure from a removed row. An append-only file's absence proves nothing.
  • Appends are transactional. Each chain append commits in its own transaction. This was verified rather than assumed, after two chains were found writing without one, where rows reached disk only when an unrelated later statement flushed the connection.
  • Peers consume each other's audit, so the record is not held only where it was written.
Where the strength actually sits

The load-bearing properties are the hash chain, the counted gaps and the transactional append: an entry cannot be altered without breaking the chain, a missing entry is distinguishable from an append that never happened, and an append either lands with its transaction or not at all. Those are the properties to test, and they hold independently of any single verification control.