Compliance & Audit
"We log everything" is what every platform says. System9's claim is different: here are many different things it can prove, and here is the mechanism for each. The platform does not have a single audit log. It has many independent, hash-chained, tamper-evident ledgers, each answering one specific question an auditor asks, so tampering with one cannot corrupt another.
In this area
- Audit and tamper-evidence: how the chains are constructed, why gaps are counted, and what an outside party can verify.
- The audit planes: how audit is partitioned by domain rather than pooled, the three kinds each domain carries (read, lifecycle and deletion), soft deletes enforced by the data-access layer, tombstones that outlive the row, and directory and federation audit.
- Metering and attribution: hash-chained, attributed accounting of activity, and device-signed metering at the edge.
- Accessible operation: the platform's accessibility conformance target, supported assistive technology, and the accessible-by- construction UI primitives operators depend on.
- Accessibility Conformance Report: the self-assessed VPAT 2.4 ACR, criterion by criterion against WCAG 2.1 AA, WCAG 2.2 AA, Section 508 and EN 301 549, with a known-issues list.
Many chains, each proving a different thing
Rather than one log filtered many ways, System9 maintains many distinct chains a structural recount in 2026 put the number at roughly three dozen, each with its own event vocabulary and its own store. The questions they answer include:
| Chain | The question it answers |
|---|---|
| Activity ledger (per workspace) | What happened in this workspace? |
| Metering audit chain | Is this invoice line real? |
| Decision audit | Why was this action allowed or refused? |
| Crypto-ledger Merkle audit | Was the key material tampered with? |
| Certificate transparency log | Was a certificate issued behind my back? |
| Policy commitment | Has this policy set changed since it was signed? |
| Clean-room ledger + signature chain | What ran in this room, approved by whom? |
| Edge device journal | What did this device do while it was offline? |
Each chain owns a distinct question, so an auditor is handed a specific proof rather than a haystack, and the conversation is about mathematics rather than trust.
Refusals and reads are recorded too
Governance decisions produce records, not just permits: a decision audit answers why an action was allowed or refused, and a withheld classification stratum emits its own record. Reads are audited, not just writes, a single read-audit chokepoint records observations with stable identifiers, so "who looked" is a first-class question.
Core and edge as one record
The edge keeps its own hash-chained journal, a signed, sequence-linked record of what a device did, including while it was offline, and that journal is designed to flush into the cell's audit stream on reconnect, back-filling the fleet's history. The integrity story runs from a physical observation, through the device's own tamper-evident journal, into the cell's audit. See Core and Edge.
Audit is described by mechanism, not by grade. Nothing here is certified. The chains are tamper-evident and each carries a verification path; cross-cell audit symmetry (peer cells consuming each other's chains) is designed but not yet transporting for most chains, and read observations are durable and attributable but are not hash-chained in production. These are mechanisms; none of this verification is certified.
Related topics
- Signing & Cryptography, the signatures and Merkle proofs the chains are built from.
- Governance (Deny-Closed), the decisions the audit chains record.
- Data Platform, where the activity ledger and lineage sit in the data plane.