ENGINEERING CASE STUDY
Preserve old evidence without rewriting history.
Blackbox migration preparation creates a cryptographic boundary around historical unchained receipt material while preserving the original bytes and explicitly refusing to pretend the old history was always V2-chained or signed.
Engineering problem
A migration can quietly destroy evidentiary meaning. It happens when historical material is rewritten into a new format and then presented as though the new controls had existed when the original record was made. That is backdating by another name: it makes the past look better-governed than it was, which is precisely the dishonesty an evidence system exists to prevent. The hard requirement is to carry old records forward without retroactively claiming guarantees they never had.
The principle: do not rewrite history
The design refuses to pretend. Legacy receipts that were never V2-chained or signed are not re-chained or re-signed to look as if they always were. Instead the migration draws a cryptographic boundary around the historical material — preserving it as what it is, pre-boundary — and marks the transition explicitly. The new controls apply from the boundary forward; the old record remains honestly old. The seam between the two eras is visible on purpose.
Implementation
The migration preparation path preserves the exact legacy bytes and records both a raw-byte digest and a canonical-row digest, so the original material is committed in two complementary ways and any later alteration is detectable. It creates a pending V2 boundary receipt that names the transition — recording that history crossed from legacy to V2 at this point — without retroactively chaining or signing the legacy history behind it. The boundary receipt is the honest join: it attests when the new regime began, not that it was always in force.
Failure controls — what it refuses
The current tests assert the refusals that keep the migration honest: bundle tampering is detected via the digests; an attempt to rebind a manifest to different source bytes is rejected, because that would be substituting history under cover of migration; a torn legacy source is refused rather than repaired-and-accepted, because a damaged origin must not be smoothed into apparent validity; an already-V2 source is refused, because re-migrating it would be meaningless churn that could obscure state; and an existing destination is never overwritten, so a migration cannot silently clobber a prior result.
Preparation is not activation
The sharpest boundary in this study is procedural, not cryptographic: migration preparation is not migration activation. Preparing the bundle, the digests and the pending boundary receipt does not switch anything into service. Existing jobs still require an operator-controlled activation and rollback procedure before any additional receipts are written against a migrated V2 ledger. The preparation is reversible and inert until a human deliberately activates it — which is the correct place for an irreversible step to sit.
Boundary
What is established is the tested behavior of migration preparation: exact byte preservation, dual digests, a non-retroactive boundary receipt, and the refusals above. What is not claimed is end-to-end migrated-ledger operation in a customer deployment — that depends on the operator-controlled activation and rollback step, which is a separately governed state.