The conceptual data model is the cleanest artifact on the project, and it usually survives right up until the first source system arrives.

If you’ve watched a data project start, you’ve seen the painting get made. Data modelers produce the beautiful diagram: entities laid out in clean ranks, relationships that read like sentences, the whole company rendered on a single page. That page earns its place. It states what the business means, and nothing downstream is trustworthy without it.

Then somebody connects a source, and the painting starts to crack.

The source does not care about your composition

The physical tables resemble that painting the way a warehouse resembles an architect’s watercolor. Keys are missing. One concept is smeared across four tables, and the column names mean nothing outside the vendor’s manual. Your engineers get handed both the painting and the warehouse, along with an instruction that sounds simple: make this look like that.

How, exactly? Nobody wrote it down. The rules that turn the source’s shape into the model’s shape were never defined. Or they were defined once in a workshop and lost in translation somewhere between the whiteboard and the backlog. Meanwhile the deadline says to land the data in the lakehouse, get people reporting, and model it properly later. Later rarely comes.

Engineers are not artists, and should not have to be

This is the friction that burns data projects. Each engineer works out the mapping by hand, keeps it in their head, and leaves the next engineer to work it out again.

Your engineers work with facts: the schemas as they are, the constraints that exist, the data that actually arrives. What they’re aiming at is something that functions. Your modelers want that something to be faithful as well, shaped the way the business thinks rather than the way the source happens to be laid out. Neither side is wrong. They’re each holding half of the same object, in two different media, with nothing that lets them join the halves.

Is that a people problem? Calling it one is the mistake. It’s a problem of medium. A model that exists as a picture can’t meet a schema, so every comparison between the two happens by hand. And every manual comparison is another place where meaning leaks out. A business model that can’t bind to a discovered schema is a poster.

How does a conceptual data model meet a real schema?

The fix is to change the medium. Record the business model as metadata instead of painting it. Every entity and every relationship becomes a versioned record rather than a box in a drawing tool. That turns the painting into a surface other things can attach to.

The physical data model gets the same treatment from the other direction. Nobody was ever going to draw those diagrams by hand. So read them straight off the source’s metadata instead. Record a schema’s tables, columns and keys, and its entity relationship diagram follows from them, with crow’s foot notation on the connectors. Your engineers get the diagrams they were never going to draw.

You now have two working surfaces, one on each side of the gap. The model is metadata, the source is metadata, and metadata can be joined. Once both sides are recorded, the question of which source table means which business entity stops being a drawing. It becomes a join. Each match is a row you can query and review, not a mapping one engineer keeps in their head.

That join is what the rest of the model meets source posts are about. The Mapping Is the Deliverable covers the mapping. It shows how each source table gets matched to the business entity it actually means, with AI proposing and a person deciding. Built, Not Painted covers the construction. That’s what to do when the source genuinely doesn’t hold the model’s shape and views have to bridge the difference.

The chapter The mapping is the deliverable in The Data Lakehouse for Everyone goes further. It takes one mapping decision apart, names who owns it, and shows what it costs to leave it in somebody’s head instead of on the record.

So stop asking your engineers to paint. Another data modeling tool won’t help if all it makes is a better picture. You need a model made of metadata, and a source recorded the same way. Before the next sprint, take one source table and write down the rules that turn it into the business entity it means, where the next engineer can find them.

In DeltaVault, the business model is a live diagram inside the catalog, and every entity and relationship you draw on it is versioned metadata.