Redacting evidence emails without breaking verification: the dual SHA-256 manifest

3 min read · 612 words
Share:
Michael Darius Eastwood
Michael Darius Eastwood · Independent AI alignment researcher
Published
Michael Darius Eastwood · Methodology · 3 July 2026
Michael Darius Eastwood, independent researcher, London: originator of the embedded-correction alignment thesis (manuscript 8 December 2024, SHA-256 anchored: f0d1f38f).

Some of the emails on the evidence page were sent to third parties: a BBC journalist, two academic recipients, an AI firm, a bishop. Publishing the raw messages would expose personal addresses, unrelated identifiers, and details that never asked to be part of a public research record. Redacting them naively, however, breaks the SHA-256 hash the whole verification chain depends on. A single character removed changes every bit of the digest. The reader cannot verify a file that no longer matches its published hash.

The solution

Two hashes per email, held in a dual manifest. The raw hash is the SHA-256 of the original .eml as it left Gmail, computed at the moment of sending and never re-computed. It is published on the evidence page but the raw file is not. The redacted hash is the SHA-256 of the redacted .eml as posted, where third-party addresses have been replaced with fixed-width placeholders and personal identifiers stripped by a documented procedure. The redacted file is downloadable; its hash is published; the reader verifies the redacted file against the redacted hash. Both hashes coexist in the manifest with an explicit note of what each one binds.

What the reader gains

A stranger downloading the redacted .eml runs shasum -a 256 and matches the redacted hash. This proves the file they hold is the exact one the programme posted, unchanged since publication. The Message-ID and the server-side timestamp survive redaction unchanged, because they identify the message itself rather than its content, so a reader can inspect them directly and confirm that Gmail's infrastructure processed a message with that ID at that moment. Transit-level DKIM verification is preserved in principle by Gmail's stores; the .eml export format does not carry the DKIM-Signature header, which is why the programme's standing phrasing is Google-server-timestamped rather than any looser claim.

What the raw hash exists for

Adjudication under subpoena or formal review. If a dispute reaches the point where a party is entitled to see the unredacted file, the raw hash gives the arbiter a fixed target: any file offered as the original must produce that exact hash. The redacted file cannot supply this test because it has been legitimately altered. The dual manifest therefore separates the two audiences: public readers who need to verify the redacted evidence they hold, and formal reviewers who at some later moment might need to verify the raw evidence held by a specific custodian.

The procedure, published

The redaction script is deterministic. Given the same raw file, it always produces the same redacted file, and therefore the same redacted hash. Anyone in possession of the raw file can therefore reproduce the redacted file and verify that the publication reflects it faithfully. The procedure itself, character-for-character, is published on the evidence page. Redaction that hides its rules is opacity; redaction that publishes its rules is a legitimate act of privacy that leaves the verification chain intact.

From the book Infinite Architects: Intelligence, Recursion, and the Creation of Everything by Michael Darius Eastwood.

Buy on Amazon UK Amazon US

Stay informed

New posts on AI alignment, convergence evidence, and the ARC/Eden research programme.

Get updates →