The Parity Receipt — A Specification

01Why it exists

Enterprises are moving decades of COBOL, fixed-width, and copybook-defined data into modern cloud, API, and AI systems. The migration itself is well-served by large vendors. What is not served is the question every risk officer, regulator, and ML team eventually asks:

"How do you know nothing was lost or silently changed?"

A naive conversion turns a packed-decimal premium into a string, flattens a variable-length array to one element, or resolves a REDEFINES union to the wrong view — and nothing errors. The numbers simply stop matching, often discovered only in production. A parity receipt makes that failure impossible to hide: either every field is provably preserved, or the receipt does not sign.

02Core principles

Deterministic. The same input bytes and the same copybook always produce the same output and the same receipt. No model, no sampling, nothing to hallucinate.
Field-complete. Parity is asserted at the level of every elementary field, not the record as a whole. A receipt claiming 80 fields preserved means 80 individually accounted-for fields.
Self-contained. A receipt can be verified from its own contents plus the original and migrated artifacts. No call back to the issuer is required.
Zero egress. The engine runs inside the data owner's perimeter. The receipt is the only thing that leaves; the data never does.

03Receipt contents

A parity receipt is a JSON object with the following fields. A reference live receipt is served at /receipt.json.

Field	Meaning
engine	Name + version of the engine that produced the receipt.
layer	`"deterministic-verification"`.
copybook	Identifier (name/hash) of the record layout the parse was driven by.
verdict	`"VERIFIED"` only if all gates pass; otherwise `"FAILED"` with the failing gate.
inputSha256	SHA-256 of the original record bytes.
outputSha256	SHA-256 of the re-encoded record after a decode/encode round-trip.
counts.elementaryFields	Total elementary fields accounted for.
counts.redefines	Count of `REDEFINES` unions resolved.
counts.occursDependingOn	Count of variable-length (`OCCURS … DEPENDING ON`) arrays.
gates	Per-gate pass/fail results (see §04).
mappings	Field-by-field map from source clause to emitted type.
schema	The emitted, executable schema the migration is contracted against.
signature	Detached signature over the canonicalized receipt body.

04The five gates

A receipt's verdict is VERIFIED only if all five gates pass. There is no partial credit.

1Structure parses. The full copybook tree resolves with no orphaned or malformed levels.

2Field count matches source. The elementary-field count equals the count derived independently from the original layout.

3Every PIC decodes. Each picture clause maps to exactly one valid concrete type — no field left untyped or ambiguous.

4Round-trip is byte-identical. Decode → re-encode reproduces the original record bytes exactly; outputSha256 == inputSha256.

5Schema compiles & validates. The emitted schema compiles and accepts the sample record.

Gate 4 is the load-bearing guarantee: a byte-identical round-trip is only possible if every field — including packed decimals, sign nibbles, and array boundaries — was decoded correctly.

05What it does and does not claim

It claims: that the migrated representation is a faithful, reversible encoding of the source record, field for field, under the supplied copybook.

It does not claim: that the source data itself is correct, that the copybook is the right one, or anything about business semantics. Parity is fidelity, not correctness of the underlying data.

06Status

This is a v0.1 draft, published to invite review from modernization integrators, BFSI risk teams, and standards bodies. The intent is a neutral, citable definition of migration parity that any tool — not only IronParse — could produce against.

Comments: pilots@ironparse.com · See a live receipt generated against a sample ACORD record.