Every data project runs on a document that does not exist: the source to target mapping that says which source table means which business entity, which column carries which attribute, and why.

You already know where that knowledge actually lives. Some of it lives in the head of the engineer who ran the last integration. Some of it lives 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 cannot tell how much of the model is real.
  • The engineer re-derives the translation table by table.
  • The next project starts the archaeology over again.

Part one of this model meets source series, Stop asking data engineers to paint, argued that the conceptual model has to stop being a painting and become metadata. This post is about the join between the two. Once the model and the source estate are both metadata, the correspondence between them becomes a recorded, reviewed deliverable instead of tribal knowledge.

How DeltaVault proposes the mapping, and why you still decide

In DeltaVault, the source to target mapping has a workbench. Open Map & Match, pick a scope (a connection, a project, or a workspace), and run it. Map & Match proposes which business entity each source table represents, then goes a level deeper and proposes which attribute each column maps to. Every suggestion arrives with a confidence score and a written rationale, and nothing changes in your model until a person accepts it.

Those proposals rest on evidence the catalog already holds rather than on naming similarity alone:

  • Table and column names are the naming evidence, and they never carry a match alone.
  • Column shape weighs in beside the names.
  • Row counts are part of the case.
  • How sibling tables were already mapped feeds the proposals.
  • Measured profiling of the column values rounds out the evidence.

From there, you choose how to review. You can step through candidates one at a time in a guided review, or you can accept in bulk at or above a confidence floor, always under an acceptance discipline your organization sets.

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. Map & Match reads that chain, so a staging table named stg_customer is proposed as your Customer entity instead of being dismissed as an unrelated table, and a table whose sibling is already mapped inherits that business entity. When you accept a match, DeltaVault offers to apply it across the whole family in one step.

Neither side waits for the other

Data mapping works whichever team arrives first. If the modelers get there first, accepting a match is a lookup into the model they already built. If the engineers get there first, accepting a business entity mapping for a table nobody has modeled creates 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. Classify the Email Address attribute a single time, and every column mapped to that attribute carries the column classification with it, across however many landing tables, staging tables, and vault satellites the attribute touches. The mapping is metadata like everything else here, 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 is one honest limit to this. A mapping records a correspondence that already exists, and nothing more. When the source genuinely does not hold the model’s shape, when Customer is smeared across three tables and a join nobody ever declared, recording is not enough and you have to build. That is the subject of the next post in the series, The model says yes, the source says no.

Chapter 5 of The Data Lakehouse for Everyone carries the same argument under the same title, working through the anatomy of a single mapping decision and the cascade that carries it across every derived copy: The mapping is the deliverable.