Re-hash a snapshot. Don’t take our word for it.

Bytes, not promises.

Fonteum stores a SHA-256 hash of every ingested source archive in the snapshot_attestations table. The hash is computed once, at the moment of ingestion, and locked. A 64-character match between your recomputed hash and the published one attests three things at once:

• Byte-exactness — the archive you fetched is byte-identical to what Fonteum ingested for that snapshot.
• No silent edit — nothing in the pipeline altered the source bytes between the upstream portal and the published dataset.
• Provenance — the snapshot ties back to a named federal source archive at a stated date, recorded on the attestation row.

This is the foundation layer. The signed, Certificate-Transparency-style chain at /docs/chain layers Ed25519 signatures and prev-hash linkage on top of these same hashes once enough snapshots have accumulated.

Five steps, one command that matters.

On macOS and Linux, shasum -a 256 (or sha256sum) is all you need. On Windows, use certutil -hashfile snapshot.bin SHA256.

# 1. Open the attestation for the snapshot you care about.
#    Browse https://fonteum.com/trust/integrity and follow any
#    "attestation →" link, or hit the attestation page directly:
#      https://fonteum.com/verify/<snapshot_id>
#    Note the published content_hash, hash_algorithm (sha-256),
#    content_size_bytes, and source_archive_url.

# 2. Re-fetch the exact upstream source archive that was ingested.
curl -L -o snapshot.bin "<source_archive_url from the attestation>"

# 3. Confirm the byte count matches content_size_bytes (cheap pre-check).
wc -c snapshot.bin

# 4. Re-hash the bytes with the same algorithm.
shasum -a 256 snapshot.bin
#    → 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08  snapshot.bin

# 5. Compare the 64-character hex against the published content_hash.
#    An exact match attests the bytes you read are byte-identical to what
#    Fonteum ingested at snapshot time. Any mismatch means the upstream
#    file changed, the download is incomplete, or the wrong archive was fetched.

Same check, in code.

Any language with a SHA-256 implementation works — the hash is computed over the raw archive bytes, nothing else. Node, stdlib only:

// Node 20+ (stdlib only) — re-hash a downloaded archive and compare.
import { createHash } from 'node:crypto';
import { readFile } from 'node:fs/promises';

// The published content_hash from https://fonteum.com/verify/<snapshot_id>
const PUBLISHED = '<paste the 64-char content_hash here>';

const bytes = await readFile('snapshot.bin');
const recomputed = createHash('sha256').update(bytes).digest('hex');

console.log('recomputed:', recomputed);
console.log('matches:   ', recomputed === PUBLISHED.toLowerCase());

A mismatch is a signal, not a dead end.

A non-matching hash usually means one of the following — work down the list before concluding the data drifted:

• Partial download — the byte count from wc -c does not equal content_size_bytes. Re-fetch.
• Upstream republished the file — federal portals sometimes re-issue an archive in place. The attestation pins the bytes as they were at snapshot date; a newer upstream file is expected to differ.
• Wrong archive — confirm you fetched the exact source_archive_url recorded on the attestation, not a sibling or index page.
• Transform vs. raw — the hash covers the upstream source archive, not the post-ingest parsed table. Hash the archive, not the rendered dataset.

If the archive is byte-complete, fetched from the recorded URL, and still doesn’t match, that is exactly the kind of discrepancy this system exists to surface — email security@fonteum.com with the snapshot id.

Where the hashes live.

• https://fonteum.com/trust/integrity — the public attestation index: every snapshot, its hash, and a deep-link to its attestation record.
• https://fonteum.com/docs/chain — the signed chain reference, with Node, Python, and Go samples that check the chain itself.
• https://fonteum.com/methodology — how each source family is ingested, dated, and attested.