86 EVERYBODY / ACCOUNTABILITY STANDARD
PUBLIC LEDGER & VERIFICATION.
A public record should be open to scrutiny—including the record maintained by its publisher. This page describes our planned method for documenting changes, checking file integrity, and allowing independent review.
The initial ledger is being developed for internal recordkeeping. Public ledger access, public repository verification, and independent checkpoints are planned, not yet active. This page is a method statement, not a certification that those protections are currently operating.
01 / PURPOSE
WHAT WE RECORD.
The ledger is intended to record material changes to published case files, source documents, redactions, corrections, removals, publication policies, and significant website presentation. Each entry will identify the affected item, the type of change, its publication status, and a timestamp. Staged work will not be represented as publicly released.
Corrections should be documented as new entries rather than silently rewriting earlier entries. When content must be withdrawn for privacy or legal reasons, the public record may describe the withdrawal without republishing restricted information.
02 / FILE INTEGRITY
DIGITAL FINGERPRINTS.
For published files, the system is designed to calculate a SHA-256 digest—a 64-character hexadecimal fingerprint derived from the exact file bytes. A reader who downloads a document can independently calculate its SHA-256 digest and compare it with the published value.
A matching digest supports that the two files are byte-for-byte identical. It does not establish that the document's contents are true, that it was lawfully published, or that it is complete.
03 / LEDGER INTEGRITY
LINKED ENTRIES.
Each ledger entry is designed to include its own SHA-256 hash and the hash of the preceding entry. A verifier can recompute the hashes in sequence. Changing an earlier entry without updating the chain breaks that verification.
This is a hash-linked ledger, not a decentralized blockchain. A publisher who controls every record could rewrite the entries and generate an internally valid replacement chain. Hash linking alone cannot rule out that possibility.
04 / INDEPENDENT CHECKS
PUBLIC VERIFICATION.
A later phase is intended to publish the ledger data, its verification instructions, and relevant code in a public Git repository. Readers could inspect historical commits and independently run the verification procedure.
However, a Git repository controlled by the publisher is not sufficient proof against deliberate history replacement. The plan therefore includes publishing periodic ledger-head hashes to independently retained checkpoints, such as third-party timestamping or independently archived snapshots. A later rewritten ledger would then have to agree with those previously preserved checkpoints to pass historical comparison.
Repository history, signed releases, and external checkpoints each offer different assurances. We will identify which controls are actually operating before describing any record as independently verified.
05 / LIMITATIONS
WHAT THIS DOESN'T PROVE.
Verification can help show whether published bytes or recorded entries have changed. It cannot independently prove the truth of an allegation, the accuracy of a summary, the absence of omitted documents, the time an event actually occurred, or the legality of publication. Publisher-supplied timestamps remain claims until supported by independently preserved evidence.
Privacy, lawful disclosure, the right of response, and transparent correction remain separate editorial responsibilities.
06 / ROLLOUT
IMPLEMENTATION PLAN.
Maintain sequential entries, compute hashes, verify chain continuity, and record actual publication events without backdating.
Publish an accessible change history, machine-readable entries, file digests, verification script, and public repository.
Publish ledger-head hashes to independently retained locations and document how readers can compare historical checkpoints.