Verify an audit chain

Every redaction job writes an append-only, hash-chained tamper-evident audit log. Each event carries the SHA-256 hash of the event before it, so altering, reordering, or removing any event changes that event's hash — and every hash after it. The final hash, the chain head, is printed on your Redaction Integrity Record.

How the chain is built

Each event's hash is computed from the previous hash and the event's canonical body:

this_hash = SHA-256( prev_hash + "|" + canonical_json(body) )

body           = { occurred_at, event_type, job_id, metadata }
canonical_json = JSON with keys sorted, no insignificant
                 whitespace, UTF-8  (e.g. {"a":1,"b":2})

The construction is deliberately simple and language-agnostic: a party holding the event records can recompute the chain in any language, so there is nothing proprietary to take on trust. The audit log records metadata only — page counts, hashes, timestamps, engine and policy identifiers — never document text.

Two ways to verify

1. In your dashboard. Signed-in customers can run the Verify chain action on any job. Lacuna walks the chain server-side and reports either “chain intact” or the exact event where a mismatch occurs.

2. As a checkpoint, over time. When you receive a Redaction Integrity Record, archive its Chain head SHA-256. Re-verify later: if the chain no longer reproduces that head hash, an event was added, removed, or altered after you archived it. Because the head hash is a one-way summary of the entire chain, this detects tampering even by Lacuna.

What this proves — and what it doesn't

Verification proves the integrity of the recorded events: that the chain you hold has not changed since the head hash you archived. It is not a regulatory certification, and it does not assert that the recorded events are complete or fit for any particular framework — those remain the customer's determination.