Part 1 of 7 · 6 min

Anyone can generate the map

Producing a source-to-target mapping stopped being hard some years ago. Part 1 of a series on migration proof: what a mapping must be before somebody outside the project signs it.

It is the Thursday before a cutover weekend, and somebody asks which mapping file is current.

Four files exist. Two came from the system integrator and one from the data team. The fourth came from an analyst who rebuilt the whole thing in March, because the others were wrong. They disagree in at least a dozen places. The file everybody actually uses is the one that analyst maintains, and the reason is that she answers her messages.

Nobody in the room can say which file is right. The migration runs on Saturday.

Danubia is the manufacturer in this story, and Danubia is an invention. It is a composite of estates we worked in, because the real ones carry names we do not use. The Thursday is not an invention. It happens on most cutovers, and the people in the room are neither careless nor unqualified.

The mapping was never the scarce thing

Here is what changed in the last few years and what did not.

Producing a source-to-target mapping became cheap. Column names are text, and matching text is a solved problem. Feed two schemas to almost any competent tool and it returns a mapping, with plausible pairs, plausible transformations and a confidence score beside each row. The mapping will be largely correct. The good tools now produce a better first draft than a junior consultant produces in three weeks.

Checking that mapping did not get cheaper at all. It still takes somebody who understands both systems, and it still takes hours per table. So the checking gets sampled, and then it gets skipped. The file the project runs on is the one that arrived first and looked confident.

That is the actual gap. Four files exist because four people generated one and nobody could adjudicate between them. Generating more mappings does not fix a problem caused by mappings being easy to generate.

What a signature has to survive

Now move the clock forward. Two years after cutover, an auditor asks how the company knows that the supplier balances it reports today are the balances the old system held.

Somebody has to answer for a decision made during the migration. That person may not be the one who made it. In most estates the artifact they inherit is a status field: a check that passed once, stored as a green result, rendered ever since. It was true on the day somebody ran it. It says nothing about today, and it cannot tell you whether the data underneath it moved.

A signature worth having survives conditions that a stored status does not. It carries what the signer relied on rather than only their name, so it still means something after that person leaves. A later correction breaks it visibly rather than leaving it in place while the ground under it moves. An outside reader can also re-check it without asking the project anything.

An artifact that argues with its own project

That is the object this series is about, and three properties make it what it is.

The proof derives from the plan. The reconciliation is not a separate deliverable that somebody writes to describe the mapping. The platform computes it from the confirmed mapping itself, so the same object that is the plan is the object the proof comes from. Nobody can author agreement into it, because nobody authors it.

The proof refuses to form over material that does not deserve it. A field pairing that only a machine suggested cannot enter a seal. A column that nobody could defensibly map stays unmapped and has to be explicitly decided by a person first. A reconciliation that does not balance blocks the seal rather than reducing its score.

And the proof re-derives itself on read. Verification recomputes the fingerprint from the current state of the estate, so a later regression breaks the seal the next time somebody opens it. There is no stored badge to go stale, because the certification is a live derivation rather than a saved result.

Where our line is

One boundary belongs here rather than in the small print, because the entire argument above depends on it.

We do not execute your migration. Coherence is not the tool that moves your data, and we do not write into your applications. The loop closes in the model rather than in your source systems. We govern the decisions, and we hold the proof about them.

That limit is deliberate and it is the reason the proof means anything. A system that both performed the transformation and certified it would be grading its own work, and an auditor discounts self-generated evidence to near zero. The transformation happens on your side, by your integrator, with your tools. What we contribute is the artifact that says whether it worked, produced by something that did not do the work.

There is a second limit, and readers of our last series will recognize it. Our confirmations cover the material somebody gave us. A system cannot be honest about tables it never read, and it says so rather than inferring.

Where this goes

The next five parts take the artifact apart in the order it gets built.

A confirmed table pair comes first, and until it exists no field mapping can be written at all. Part 3 covers the closed list of things that may happen to a value. The one open-ended operation is quarantined there, so it can never confirm itself. Part 4 takes the column that gets no target, which is where we would ask a skeptical reader to begin. The two parts after that cover the reconciliation the platform derives rather than accepts, and the seal that declines to form.

The last part returns to the buyer, because a migration is not only data. Custom code, configuration and process each need their own verdict. The signature at the end must be one that no single person could produce alone.

Start with Thursday. Four files, one weekend, and no way to choose. The next part opens on the question the room could not answer. What must a mapping be, before somebody outside the project signs it?

Part 2: The pair before the columns. Why a suggestion and a decision are different objects in the model, and why one confirmed table pair comes first.

part 2 →The pair before the columns

Model your first domain today.

You send five documents, we model them, and the first cut comes back in days.