Bill Inmon defined a data warehouse in four words: subject-oriented, integrated, time-variant, non-volatile. Three of those four still get built as a matter of course. Integrated is the one the industry quietly let go, and you can watch it happen in any demo where an AI reads a source schema and hands back a finished model, with no view on which name for Customer is the preferred term and which ones are synonyms.

Three models, three Customers

The AI data modeling wizards are genuinely good. Point one at a source system and it infers the keys, proposes the relationships, sorts the columns into the structures your target pattern expects, generates the load, and writes a rationale for every call. Run it against your second and third sources and you are finished by Thursday.

Then look at what those clicks produced: one model per source, each with something called Customer in it, keyed three different ways, and not one of them nominated as the golden record, the version the business treats as authoritative. Land all of it in one platform and you have moved data rather than integrated it. That is replication, and it is still replication when the target is a lakehouse and the schema is inferred: your operational estate, copied, with better naming and a lineage diagram on top.

None of that is the AI falling short. It is a question the input cannot answer. A source schema records how one system stores its own customers, and nothing in it tells you whether the customer in billing is the same person as the customer in support.

Why is data integration a decision, not a derivation?

Data integration has always been the expensive part of the job, and almost none of that expense is technical. Someone still has to decide that a billing account, a login, and a sales contact are three views of the same Customer. That decision forces two more. You pick which identifier the business treats as authoritative, and write the survivorship rule for the two that lose: which value wins when the sources disagree, and whether the losing identifiers are kept as aliases or dropped. Then you have to capture that definition in writing, because the rest of the company gets measured against it from that point on.

Skip that work and everything downstream looks tidy without being true. You can generate a flawless model for each of the three systems and still not know how many customers you have. The gap is not in any one model. It sits between them, in the agreement nobody made.

How DeltaVault splits the drafting from the deciding

The decisions stay yours. But the work in front of you is wide, repetitive, and evidence-driven, exactly the shape of problem AI is good at.

DeltaVault splits that work in two. It starts with an AI-native workshop that walks you and your business stakeholders through the entities, relationships, and definitions before any source schema gets a vote. You answer what a Customer is, which identifiers the business recognizes, and which of those it treats as authoritative; the workshop drafts the conceptual and logical model from those answers and keeps the reasoning attached to them. You end up with a governed business model that stands independent of any system feeding it.

Map & Match connects your sources to that model. It reads your tables, columns, entities, attributes, and glossaries, then proposes which business entity each source table represents and which attribute each column maps to. Because the mapping terminates in the business model rather than a physical target, lineage runs at the business level: a governed attribute traced back to every column that populates it. Every suggestion carries a confidence score and a rationale, and nothing changes until you accept it. Run it across a project instead of one connection and every system’s tables match against one set of entities, so the same Customer comes back proposed three times.

That disagreement is the point. Duplicate names are allowed on purpose, because real businesses have synonyms, and the model records which one is the preferred term and keeps the rest as registered aliases rather than forcing a winner. Where the business does need one value to win, the call on which system is the authoritative source for that attribute stays yours to make. The definition lives on the attribute, moves from Draft to Approved with a stamp of who approved it and when, and drops back to Draft the moment anyone edits it.

Fuse it or lose it

A glossary everyone nodded at in a workshop is still a slide. Integration becomes real only when the agreement is written into a key that every load has to honor. That means each staging table carries one designated business key, and everything downstream is named for the business entity rather than the system it arrived from. Do that and three tidy source models become one integrated data warehouse: point a second feed at the model, and it lands on the Customer you already hold as the golden record.

Which is why integration deserves more of your attention than the pipelines around it. Until the answer to who counts as a customer is captured, approved, and bound to a key, every downstream number is an estimate defended by whoever ran the query last.

The workshop drafts the model, Map & Match drafts the mappings, and you keep the calls that matter:

  • The golden record: which identifier becomes it.
  • The authoritative source: which system stands as it for each attribute.
  • The preferred term: which name it is, and which are synonyms.
  • The definition: what it says when finance and support disagree.

That division of labor holds up as sources three, four, and five arrive. Bring the business model in before the next source.

Chapter 6 of The Data Lakehouse for Everyone weighs four integration shapes against that division of labor: Choose an integration shape without a religion.