Every data project runs on a document that doesn’t exist. It’s the source to target mapping: which source table means which business entity, which column carries which attribute, and why.

So where does that knowledge actually live? You already know. Some of it is in the head of the engineer who ran the last integration. Some is in a spreadsheet built to a deadline and half updated since the workshop that produced it. Mostly it lives nowhere, and everyone downstream pays for the gap. The modeler can’t tell how much of the model is real. The engineer re-derives the translation table by table. And the next project starts the archaeology over again.

Stop asking data engineers to paint argued that the conceptual model has to stop being a painting and become metadata. Once the model and the source estate are both metadata, the data mapping between them becomes a recorded, reviewed deliverable instead of tribal knowledge.

What should a source to target mapping record?

A mapping, once it’s written down, is a small record with a fixed shape. It holds the physical thing, the business thing it means, a confidence in the pairing, who decided, when, and why. That’s a recorded mapping.

A pairing can start as a proposal, and a proposal should arrive with its confidence and a written reason. The reason should rest on evidence, not on naming similarity alone. That evidence is table and column names, column shape, row counts, how sibling tables were already mapped, and measured profiling of the column values.

But a proposal isn’t a decision. So who decides? A person does, and nothing changes in your model until they accept the pairing. You can step through candidates one at a time, or accept in bulk at or above a confidence floor. Either way, your organization sets the acceptance rules, including where that floor sits. A mapping a person made is never silently overwritten by a later pass.

The staging copies come along

Source data rarely arrives once. It arrives as a family: a landing copy, a staging copy, and a persistent staging copy, all descended from one source table. Whoever proposes a match should read that chain. Read that way, a staging table named stg_customer is proposed as your Customer entity, not dismissed as an unrelated table. A table whose sibling is already mapped inherits that business entity. One accepted match covers the whole family.

Neither side waits for the other

Mapping works whichever team arrives first. If the modelers get there first, accepting a match is a lookup into the model they already built. What if the engineers get there first? Accepting a business entity mapping for a table nobody has modeled can create a skeleton entity, marked as derived. That skeleton is still a real entity. It carries data governance from day one, and the modelers can adopt it into the full model when they catch up. Either way, the translation stops being a phase one team waits on.

What does a recorded mapping buy you?

Record the correspondence once and meaning starts to travel along it, column classification included. Classify the Email Address attribute a single time. Every column mapped to that attribute then carries the classification with it, across however many landing tables, staging tables, and vault satellites the attribute touches. The mapping is metadata like everything else in the catalog. So it gets proposed on a branch, reviewed, and committed, with a history of who accepted what and when. That gives you data lineage for a decision rather than for a row.

The rules are no longer lost in translation. They are the deliverable.

There’s one honest limit to this. A mapping records a correspondence that already exists, and nothing more. When the source genuinely doesn’t hold the model’s shape, when Customer is smeared across three tables and a join nobody ever declared, recording isn’t enough. You have to build.

That’s the argument of Built, Not Painted and of The model says yes, the source says no, two more model meets source posts.

The Data Lakehouse for Everyone has a chapter, The mapping is the deliverable, that carries the same argument under the same title. It works through the anatomy of a single mapping decision and the cascade that carries it across every derived copy.

Before you read on, record one mapping. Pick the one that lives in someone’s head today. Write it down in whatever your team already uses: the source table, the business entity it means, who decided, when, and why.

That’s the first row of the document that didn’t exist.

In DeltaVault, Map & Match proposes each pairing with a confidence score and a written rationale, and accepting a source table’s entity maps its landing, staging, and persistent staging copies in the same step.