Verify it yourselfDon’t trust the audit log. .
Most security products ask you to believe their logs. Your own team can confirm the record is intact, without taking our word for it. The verifier ships to you and runs on your systems.
The chain verifier
redactwall verify-audit-chain reports one of four results: verified intact, broken at sequence N, could not verify, or verified, tail uncovered. A run with an uncovered tail says so, rather than reporting a plain success.
Example output: the tenant chain, reproduced in the format the command prints
$ redactwall verify-audit-chain --plane tenant --anchor /var/lib/redactwall/anchor verify-audit-chain: plane tenant, tenant ten_a1a1a1a1a1a1a1a1a1a1a1a1, environment env_b2b2b2b2b2b2b2b2b2b2b2b2, cell cell_c3c3c3c3c3c3c3c3c3c3c3c3 verify-audit-chain: head sequence 3, key version 1 verify-audit-chain: head digest sha256:e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4e4 verify-audit-chain: walked 3 entries through sequence 3 verify-audit-chain: ingest_event 3 verify-audit-chain: signed checkpoint at sequence 3 matches this chain's entry there verify-audit-chain: VERIFIED - every entry from 1 to 3 re-derived under its own key and MAC domain, and every link digest matched its predecessor.
Example output: the platform identity chain, with the two disclosures it always prints
$ redactwall verify-audit-chain --plane platform --checkpoint /var/lib/redactwall/identity-checkpoint verify-audit-chain: plane platform, chain platform_identity (one chain, deployment-wide) verify-audit-chain: head sequence 4, key version 1 verify-audit-chain: head digest sha256:f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5f5 verify-audit-chain: walked 4 entries through sequence 4 verify-audit-chain: identity_mutation 4 verify-audit-chain: signed checkpoint at sequence 4 covers this chain through its head. This chain's checkpoint is PERIODIC, not per-commit: entries appended after a checkpoint are covered by NO checkpoint until the next one is published. Nothing is uncovered as of this run. THIS CHECKPOINT'S BINDING TO THIS DATABASE IS DECLARED, NOT ATTESTED. It authenticates under REDACTWALL_PLATFORM_DATABASE_IDENTITY, a value the operator configured. This plane has no storage_identity relation, so nothing here re-proves that value against the database in front of you, and this run read no attestation of it -- the tenant plane re-proves its own on every transaction and this plane cannot. A checkpoint directory paired with a database that was COPIED TOGETHER WITH ITS CONFIGURATION therefore authenticates here, and this command cannot tell that copy from the database the checkpoint was written for. verify-audit-chain: VERIFIED - every entry from 1 to 4 re-derived under its own key and MAC domain, and every link digest matched its predecessor.
The second chain is the platform identity chain: the record of who was provisioned and what was enrolled. Every run against it that reads a checkpoint prints two disclosures, reproduced in the example output above.
The two disclosures, in plain terms: this chain’s checkpoint is periodic, so entries added after it are covered by no checkpoint until the next one is published; and its binding to the database in front of you is declared by the operator, not attested by the product.
The examination package
Period-scoped and signed
redactwall export-examination-package produces a signed bundle for a stated reporting window. The scope is immutable; the bundle proves fixity and provenance for exactly the window it names.
No database. No configuration. No key of ours.
redactwall verify-examination-package checks a bundle standalone. A third party can validate what they were handed without access to any RedactWall system, ours or yours.
Why this exists
Every decision lands on a record that cannot be quietly edited. If someone alters the record, the change shows up instead of passing unnoticed. That is what makes the verifier meaningful: there is something real for it to check.