How to verify a ForensicBlock record without ForensicBlock

1.What is sealed

• A sealed record commits to a JSON object called the PACKET.
• The commitment is a SHA-256 digest over the UTF-8 encoding of the packet's canonical form.
• The packet is published in full by the public verifier in JSON form, so a reader holds the same bytes the digest was taken over.

• The packet is not the report PDF. The packet records the report's identity, its PDF digest, the methodology version, the signer, and whether an examiner declaration exists. The PDF is committed to separately, by the pdf_hash_sha256 field inside the packet.

2.Canonicalisation — RFC 8785

• The canonical form of a packet is its RFC 8785 (JSON Canonicalization Scheme) serialisation.
• RFC 8785 is the normative reference. Where this document and RFC 8785 disagree, RFC 8785 governs.
• In summary: object members are sorted by key using UTF-16 code-unit order; there is no whitespace; strings escape only the reverse solidus, the quotation mark, and the C0 controls (below U+0020), using \b \t \n \f \r where defined and \u00xx with lower-case hex otherwise; array order is preserved exactly; the output is UTF-8.
• A packet sealed on or after 2026-08-25 declares its own scheme, carrying "canonicalization":"RFC8785" and "digest_algorithm":"SHA-256" as packet members.

• The solidus (/) is NOT escaped. Escaping it is the most common way two implementations silently disagree.
• Non-ASCII characters are emitted LITERALLY as UTF-8, not as \u escapes. An em dash in a report title appears as the three bytes E2 80 94.
• An independent TypeScript implementation written for a different code path on 2026-04-27 produces byte-identical output to the current one on real packets. Three implementations agreeing is the evidence that this is reimplementable rather than merely specified.

3.The packet digest

• packet_sha256 = lowercase hexadecimal of SHA-256 over the UTF-8 bytes of the RFC 8785 canonical form of the packet.
• To verify: obtain the packet JSON, canonicalise it per section 2, hash it, and compare to the recorded packet_sha256.
• Canonicalisation is idempotent: parsing the canonical form and canonicalising it again yields identical bytes. An implementation that does not have this property is incorrect.

4.The append-only audit ledger

• Every consequential act, including sealing a report, appends one entry to a hash-chained ledger.
• Each entry carries prev_hash (the entry_hash of the immediately preceding entry, ledger-wide) and its own entry_hash.
• entry_hash = lowercase hexadecimal of SHA-256 over a preimage string formed by joining, with the single character '|': the entry id; prev_hash; event_type; org_id; actor_user_id; actor_kind; subject_type; subject_id; the payload; methodology_version; and recorded_at rendered in UTC as YYYY-MM-DDTHH:MM:SS.ffffffZ. An absent value contributes the empty string.
• The proof bundle ships this preimage string verbatim for every entry it references. A verifier SHA-256s the shipped preimage and compares it to the entry_hash; no database is involved.

• LIMIT, stated plainly: the payload appears in the preimage as the database's own JSON serialisation, which is NOT the RFC 8785 form and is not independently specified. Recomputing an entry_hash from the payload as structured data therefore requires that serialiser. Verified on production: three of three sampled entries reproduce from the database serialisation and none reproduce from the RFC 8785 form.
• Shipping the preimage removes the consequence rather than the cause: a verifier hashes a plain string and reads the packet digest inside it, so the step is fully independent even though the composition rule references a serialiser we cannot ask a stranger to reimplement. Changing the composition would invalidate the existing chain and is not done.

5.The daily Merkle root

• For one organisation and one UTC day window [window_start, window_end), the leaves are the entry_hash values of every ledger entry belonging to that organisation whose recorded_at falls in the window, ordered by recorded_at ascending then id ascending.
• Each leaf is the 32 RAW BYTES obtained by hex-decoding entry_hash — not the hexadecimal text.
• A parent node is SHA-256 over the concatenation of its two children's raw 32-byte values.
• If a level has an odd number of nodes, the final node is DUPLICATED and hashed with itself. It is not promoted unchanged.
• The root is the lowercase hexadecimal of the single remaining node. A window containing exactly one entry has that entry's hash as its root.

• Verified: five of five sampled attestations reproduce their stored merkle_root exactly under this construction, with matching entry counts and first/last entry ids.
• The database also contains a similarly named helper that builds a DIFFERENT tree — over an id range rather than an organisation-scoped time window, hashing hexadecimal text rather than raw bytes, and promoting an odd node rather than duplicating it. It is not the construction that produced any stored root, and an implementer following it will not reproduce one.

6.The independent timestamp — RFC 3161

• Each daily Merkle root is submitted to a Time-Stamping Authority and the response is retained.
• The retained artifact is a complete TimeStampResp (RFC 3161 section 2.4.2), not a bare TimeStampToken. Tools expecting a bare token must first extract it.
• The token's messageImprint is the SHA-256 Merkle root of section 5, byte for byte.
• The full certificate chain is embedded in the token, so verification requires no network access.
• To verify: openssl ts -verify -digest <merkle_root_hex> -in <attestation>.tsr -CAfile <tsa_root>.pem

• Verified offline with no network reachable: Verification: OK. Both negative controls fail correctly — a single flipped bit in the digest yields "message imprint mismatch", and an incorrect trust anchor yields a certificate chain error.
• LIMIT, and it is the largest one on this page: the checks above have been run on SAMPLED tokens, not on every token. The structural properties — response format, imprint equal to the Merkle root, chain embedded — were measured across the whole population, but a structural check is not a signature check, and a fabricated blob can satisfy all three while failing openssl outright. Until every token has been through a real signature verification, the supportable sentence is that the FORMAT is established for the population and the SIGNATURE is established for the samples. This page will carry the token-by-token count when it exists.
• LIMIT: the timestamping authority used for the large majority of these attestations publishes a self-signed root that is in no operating-system trust store, under a policy identifier taken from OpenSSL's example arc. That does not make the timestamps false — they verify — but an opposing expert may fairly characterise the authority as informally operated, and a reader should weigh it as one corroborating time source rather than as the decisive one. The Bitcoin anchor of section 7 does not depend on it.
• LIMIT: the bundle ships the TSA's root certificate so the check RUNS offline, but trusting OUR copy of that root is circular. Anchor it to the authority's own published root, or to your operating system's trust store. Where the chain terminates at a widely distributed commercial root, no file from us is needed at all.

7.The Bitcoin anchor — OpenTimestamps

• Each daily Merkle root is also submitted to OpenTimestamps, and the resulting .ots proof is retained.
• The proof's file digest is the Merkle root of section 5. Verified across the entire corpus: 2,077 of 2,077 proofs commit to exactly their stored root.
• A proof shipped in a bundle contains a complete path to a Bitcoin block header attestation, so verification does not depend on any OpenTimestamps calendar server remaining available.
• To verify: follow the proof's operations to a Bitcoin merkle root and block height, then read that block's merkle root from any Bitcoin node or block explorer and confirm the two are equal.
• The block's timestamp is then an upper bound on when the Merkle root — and therefore every record committed under it — existed.

• Worked example, verified 2026-08-25: attestation 4a3a9028 commits to root 13ddd015de735e583dd3777feb9b96c6623cfd37b19eba386c8639f9fce8a26a; its proof reaches BitcoinBlockHeaderAttestation(963810) by two independent calendar paths and computes block merkle root d7b62bb8ae7351938c53debca4c96310eb7aeeba1d815a2df8062b9bd17236e0. Block 963810's actual merkle root, read from a public explorer, is identical.
• A proof may retain pending calendar branches alongside its completed Bitcoin path; their presence does not mean the proof is incomplete. The property to assert is that a Bitcoin block header attestation is PRESENT in the bytes, not that no pending branch remains.
• Measured on the bytes rather than on a status column: 2,042 of 2,077 proofs carry a Bitcoin attestation, across 37 distinct blocks between heights 955,363 and 963,810. The remainder are recent windows whose confirmations have not yet been folded in.
• READ THE BOUND EXACTLY, because it is easy to read more into it. The anchor establishes that the root existed BEFORE the block. It establishes nothing whatever about how long before, and in particular it does not establish that the root was created on the day its window closed. Where a root was submitted to the calendars some time after its window closed, the Bitcoin evidence is silent about the interval between the two, and a bundle must state the submission time so a reader can see the gap rather than assume there is none.
• The honest per-record sentence therefore names three separate moments — when the window closed, when the root was submitted, and which block it landed in — and never collapses them into one.

8.What this establishes, and what it does not

• ESTABLISHED: the packet's bytes are fixed to the recorded digest, and any change to them produces a different digest.
• ESTABLISHED: the ledger contents committed under a given Merkle root existed no later than the timestamp of the Bitcoin block that root is anchored in.
• NOT ESTABLISHED: that the statements inside the record are true. A seal fixes what was said, not whether it was correct.
• NOT ESTABLISHED: that a human examiner attested to the record. An examiner declaration under 28 U.S.C. section 1746 is a SEPARATE sealed record referencing the first, with its own digest and its own verify address. A record without one is complete and verifiable; it simply carries no sworn opinion.
• NOT ESTABLISHED: the identity of the signer beyond the account recorded in the packet.
• A check that cannot be performed is reported as not performed. It is never reported as a failure, and never as a finding that a record was altered.