The examination packageEvidence a third party can check without us.
One command exports a period-scoped, signed bundle for a stated reporting window. A second command checks that bundle standalone, with no database, no configuration and no key of ours.
What the bundle is
A bundle is not an export of a console view. It is drawn from entries written when decisions were made on governed paths. Entry changes make verification fail, and a signed checkpoint exposes removal of entries it covered.
The window it names, and nothing else
You state the reporting window at export, and it is fixed from then on. A reviewer who asked for one period receives exactly that period, not a filtered view of a live system that could be filtered differently tomorrow.
Byte-for-byte what was exported
The bundle is signed. If anything in it changed after export, whether in transit, in a mailbox, on a share or in the recipient’s own hands, verification says so rather than passing quietly.
Where the records came from
Each entry is written by the component that made the decision, at the moment it was made, rather than assembled afterwards from a console view.
Two commands
The export runs where your evidence lives, and the verifier runs anywhere. That is the point: whoever you hand the bundle to can check it without access to your systems.
$ redactwall export-examination-package
# produces a signed bundle for the reporting window you state
$ redactwall verify-examination-package
# checks that bundle standalone: no database, no configuration, no key of ours
What a verification result tells you
A verification run states what the bundle covers rather than a bare pass or fail, and the check on the record itself names what it covered the same way. verified, tail uncovered means the whole record checked out and the most recent entries are not yet sealed, which a plain pass would hide.
Example audit chain verified.
$ redactwall verify-audit-chain --plane tenant --anchor /var/lib/redactwall/anchor
verify-audit-chain: plane tenant, tenant ten_a1a1a1a1a1a1a1a1a1a1a1a1
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: 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, reproduced in the format the commands print. The identifiers and digests are examples, not values from any deployment.
Using it in a review
Export at the close of the period rather than in the week the request arrives.
The scope is fixed at export, so a bundle produced under time pressure is no more authoritative than one produced calmly.
Hand the bundle to whoever asked, and hand them the verifier with it.
They check what they were given before anyone relies on it, on their own machine.
Run the record check separately on your own systems and compare the result.
The bundle check shows whether the exported bytes changed. The record check checks the entries present and reports checkpoint coverage; it does not prove every event was recorded.
Know what the package is for.
It gives you material to hand to a reviewer. Disclosures states what RedactWall claims today.
Start a supervised pilot.
See the coverage table for what each surface does, or start a pilot and export a bundle from your own window.
- A named reporting window and governed scope
- Integrity checked on the recipient’s systems
- The verification report states its limits