What an auditor actually wants to see after a data migration
Every data migration ends in the same room. The system is live, the cutover went fine, and then someone from risk, internal audit, or the regulator asks the one question that decides whether the project is actually finished: show me nothing was lost. Not "show me it works." Show me that the records that came out are the same records that went in — every field, every account, every cent.
Most teams cannot answer that question well. They can answer adjacent questions, and they hope the adjacent answers are close enough. They usually aren't.
Why the usual artifacts don't hold up
Screenshots. A side-by-side of the old screen and the new screen proves one record looked right on one day to one person. It proves nothing about the other four million records, and it isn't reproducible — you can't re-run a screenshot. An auditor treats it as an anecdote, not evidence.
Row counts. "We had 4,210,118 rows before and 4,210,118 after" feels rigorous and tells you almost nothing. Counts match while the contents inside each row are silently corrupted — a packed decimal misread, a sign flipped, a coverage array truncated. The row is still there; the data in it is wrong. This is exactly the silent data loss that passes every count and still fails reconciliation.
Sampled spot-checks. Pulling 200 records and eyeballing them is the honest version of the row count, but it's still a sample. A 0.01% corruption rate is invisible to a 200-record sample and catastrophic across millions of policies. An auditor knows the math: a sample bounds your confidence, it never proves completeness.
"The vendor said so." The migration vendor attesting that their own tool worked is the weakest artifact of all. It fails the most basic test of evidence — independence. The party that did the work cannot also be the party that certifies the work. No regulator accepts a self-graded exam.
What auditable evidence actually needs
Strip away the format and an auditor is looking for four properties. Evidence that has all four survives scrutiny; evidence missing any one of them gets discounted.
Independent. The check has to come from something other than the migrator. If the same logic that transformed the data also validates the data, an error in the transform is invisible to the validation — they share the same blind spot.
Reproducible. Run the check again and get the identical result. If the outcome depends on who ran it, when, or against which snapshot, it's an observation, not proof. Reproducibility is what lets an auditor re-run it themselves instead of taking your word.
Complete. Every field of every record, not a sample. Completeness is the property a spot-check can never have, and it's the one the "nothing was lost" question is actually asking about.
Signed. The result has to be attestable — bound to a specific input, a specific output, and a specific point in time, in a way that can't be quietly edited after the fact. An unsigned report is just a document; a signed one is a statement someone is on the hook for.
How a parity receipt maps to each
This is the gap a parity receipt is built to close. It isn't a report a human writes; it's a deterministic artifact a verifier produces, and each of its parts lines up with one of the four properties.
Reproducible comes from hashing. The receipt records the SHA-256 of the exact input record and the SHA-256 of the exact output. Anyone can re-run the verification against the same bytes and get the same hashes — a single changed bit anywhere produces a different digest. The result doesn't depend on who runs it.
Complete comes from field counts plus the five gates. The receipt asserts the field count it decoded and runs every record through five deterministic checks — structure parses, field count matches the source, every PIC clause resolves to a concrete type, the emitted schema compiles, and the re-encoded bytes round-trip to the original. That's every field, not a sample of them.
Attestable comes from the signature. The receipt is signed, binding the input hash, the output hash, the gate results, and the timestamp into one tamper-evident object. Change anything and the signature breaks.
No chain-of-custody gap comes from where it runs. The verifier runs inside your perimeter with zero data egress — the records never leave the environment they're already cleared for. There's no third party to trust with the data and no "we shipped it to a vendor and they sent back a PDF" hole in the story. Independence without handing your data to someone else.
The artifact you can hand a regulator
The reason this matters isn't elegance. It's that a risk or audit team finally has something they can put in front of an examiner and defend line by line: independent of the migrator, reproducible on demand, complete across every field, and signed. The deeper case for verifying migrations this way — especially as more of this work shifts to AI-driven tooling — is laid out in mainframe to AI.
The parity receipt is the difference between telling a regulator the migration worked and handing them the proof.
Read the spec
The Parity Receipt is a defined, deterministic artifact — input/output hashes, five gates, a signature. Read exactly what it asserts, or generate one against a sample ACORD record.
The Parity Receipt spec → Live parity receipt