Did the revision change the history — or only its packaging?
Quantitative sources are not still: regulatory extracts resubmit weekly, adverse-event quarters arrive with deletions, vendors restate, re-encode, re-order. Everyone downstream owes the same claim: this revision changed the history my state was built on — or it changed only the file.
the pain
Today the choice is bad in both directions. Byte-diff the files and everything looks changed — a re-sort or re-encode lights up every row. Compare within a tolerance and you have handed the party being audited an ε to hide a material restatement inside. Pharmacovigilance teams must decide whether a FAERS resubmission alters a signal evaluation; quant data-ops whether a vendor restatement invalidates a fitted history; credit modelers whether a refreshed regulatory extract is “the same data.” There is no instrument that grades a revision by its effect on what downstream decisions actually read.
the process today
Data-versioning systems — time-travel tables, content-addressed lakes — answer which version perfectly and does it matter not at all. Schema-diff and data-quality tools compare marginals against tuned thresholds. And any ε-based comparison of derived state hits the no-universal-tolerance wall: benign noise and a real restatement can be the same size. What is needed is an equivalence class that absorbs benign transformations exactly, and a floor under “material” that is not chosen by the party with an interest in the answer.
the cost
Accept every refresh and a silently material restatement invalidates the fitted history downstream of it. Refuse every refresh and operations stall on packaging noise. Negotiate a tolerance and the vendor knows exactly how large a change can hide inside it. All three costs land on the team that must certify, later, what their state was built on. And for a bank that responsibility is codified: SR 26-2 keeps model risk with you even when the model is a vendor’s — where their code is closed, it points you to outcomes analysis. When the vendor restates, you owe evidence that you governed the change, not that you trusted them: recompute whether it moved the history, or only its packaging.
the exhibit — recompute it yourself
corpus: real pinned data — CFPB HMDA Dynamic dataset (modified LAR), DC/2022, which resubmits weekly · snapshot A: 2026-06-16 pull, n=28,264 (the published vectors) · snapshot B: 2026-06-30 pin, n=28,301, raw CSV sha256-pinned (dad83a6c…) · declared 10-feature schema; the kit re-derives them from the raw CSV with a standalone numpy routine, byte-equivalent on the pinned CSV · ties to the shipped HMDA non-influence certificate. Register: detection — the global argmax sits on the denied×denied diagonal, not the protected coupling.
On localization, stated precisely — this page used to call it “measured false”, and that was the wrong word. The cell that beats the protected coupling is denied×denied — a diagonal, i.e. a variance term rather than a relation between two variables. Diagonals are structurally large and churn-heavy, so they top rankings for reasons unconnected to any declared step, and they are not candidate answers to “did the revision move this coupling?” So localization here is not false; it is not claimed, and the honest reason is the ranking convention, not a measurement that came back negative. And it would not be worth claiming even if it ranked first: this receipt's declared forge drops 843 of 1,686 race_black ∧ denied records — it targets that exact cell by construction. A ranking that nominates the cell we ourselves moved is the control succeeding, not the geometry discovering. Detection is the claim; the register is correct and stays.
The benign-equivalence class is exact: a re-ordering or re-serialization lands on the byte-identical geometry digest. No tolerance to negotiate — cosmetic means collides, not close.
This red is a forge we run as a brake test — the committed certificate’s own launder_denials control, reproduced from the raw pinned CSV (agreement to 1e-9 relative). A restatement dressed as packaging cannot pass: the digest moves, and the move rings two orders of magnitude past the floor.
And the real revision itself, graded: the source’s own weekly resubmission (335 rows removed, 372 added under the same query) lands at max|Δg| = 0.0492 ≈ 4.6 null-widths past the corpus’s own churn floor → MATERIAL. The floor is the measured cost of a same-shape resubmission carrying only the field’s accumulated mass (200 seeded draws, declared convention 3.0) — not a vendor-negotiated threshold. The verdict is reported whichever way it lands; this one landed past the floor: the refresh genuinely changed the history, not just its packaging.
recompute fingerprint — the canonical g-digest of the pinned snapshot the
kit’s verify step reproduces from the raw CSV alone, byte-for-byte on any engine that follows the
kit’s published canonicalization · v3 =
150c2313632ed2bfd6600b494dbc3d24d3b4ce05bf29a442df7f488dcaa7aebb
kit fingerprint · sha256 =
6134fda10aaab2742f235f22697db0185625a2421f645b532aa223359476663f
The verifier re-extracts the
declared schema from the raw pinned CSV, recomputes every geometry, and issues the three-way
verdict — GREEN re-export, graded revision, refused forge — in a clean environment (numpy only).
the relief
A revision-materiality receipt replaces both bad options with a decidable grade: cosmetic revisions collide exactly — different bytes, byte-identical geometry, nothing to argue — and consequential revisions are measured in the record’s own null-widths, a floor the vendor cannot negotiate because the corpus priced it itself. “Is the refresh the same data?” becomes a verdict either side can recompute from the pinned artifacts.
what this does not prove
Materiality here is relative to the declared schema and the induced metric — a revision that matters to a column the schema does not carry is invisible, and this certificate names its ten features. RED is detection, not diagnosis: the revision moved the geometry past the floor, and where it moved it is a separate measured claim — here the global argmax sits on a low-variance diagonal (denied×denied), not the protected coupling, so the wording stays at detection. The receipt binds the pinned snapshots, recorded checksums and dates — the live endpoint keeps drifting after the pin. The verdict grades geometric consequence, not contractual meaning: whether a material restatement breaches a data agreement is a human’s resolution. And certifying your feed this way requires your record accumulated on the substrate — the frontier condition: adopt the substrate to get the receipt.
“Did the data change?” has always had two useless answers: always and within tolerance. This receipt is the third one — exact where it should be exact, floored by the record itself where it must measure — recomputed on your bench.
The longer read — the landscape of recomputable data boundaries these receipts extend — is in the docs.
verify this receipt in your browser
This case's receipt records its verdict and both digests above, and carries its own SHA-256. Recompute it here — WebCrypto, in your tab, nothing sent — and it matches; alter one character of a copy and it fails. It is the smallest version of the whole move: recompute, don't trust. The kit below lets you recompute the geometry digest itself on your bench.
published fingerprint ·
or download this receipt and check it on your bench:
receipt-revision-materiality.json
— shasum -a 256 prints the same number. Every receipt is on
the ledger.
request the kit
The revision-materiality receipt kit — pinned snapshots, forge, manifest,
verify.py. A person sends it: the kit and its
verification steps arrive by reply, usually within a business day.
← Receipts · Docs · Ledger