Bill Inmon defined a data warehouse in four words: subject-oriented, integrated, time-variant, non-volatile. Integrated is the one the industry quietly let go. You can watch integration go missing in any demo where an AI reads a source schema and hands back a finished model. The model has no view on which name for Customer is the preferred term and which 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 and proposes the relationships. It 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’re finished by Thursday.

So what did those clicks produce? You have one model per source, each with something called Customer in it, keyed three different ways. Not one of them is nominated as the version the business treats as authoritative. Land all of it in one platform and you’ve moved data rather than integrated it. That’s replication, and it is still replication when the target is a lakehouse and the schema is inferred.

None of that is the AI falling short. It’s a question the input can’t answer. A source schema records how one system stores its own customers. 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. 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 whether the two that lose are kept as aliases or dropped. And where matched records disagree, someone rules, attribute by attribute, on whose value survives. That ruling is a survivorship rule. When a requirement calls for one combined record per customer, those rulings build it: the golden record. Then you have to put the Customer definition in writing, because the rest of the company is measured against it.

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. So where’s the gap? It isn’t in any one model. It sits between them, in the agreement nobody made.

AI drafts the candidates, and you rule on each

The decisions stay yours.

But the work in front of you is wide, repetitive, and evidence-driven. That’s the shape of problem AI is good at. An AI can draft the candidates: which tables describe the same Customer, which name is the likely preferred term, and which identifier the evidence favors as authoritative. You rule on each one.

Start with the business model, before any source schema gets a vote. You and your business stakeholders answer what a Customer is, which identifiers the business recognizes, and which of those it treats as authoritative. An AI drafts the conceptual and logical model from those answers, with its reasoning beside each proposal. You end up with a governed business model independent of any system feeding it.

Then connect your sources to that model. An AI reads your tables, columns, entities, attributes, and glossaries, and proposes which business entity each source table represents and which attribute each column maps to. Because the mapping ends in the business model rather than a physical target, it records which governed attribute each column populates. Each suggestion carries a confidence score and a rationale, and nothing changes until you accept it.

Match every system’s tables against one set of entities, and the same Customer comes back proposed three times.

That disagreement is the point.

Duplicate names are allowed on purpose, because real businesses have synonyms. The model records which one is the preferred term. The others stay as entities in their own right, and no winner is forced. Each definition lives on the attribute it defines, approved by a named person on a known date, and any edit sends it back to draft.

A glossary isn’t integration until a business key carries 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 that feeds a hub carries one designated business key, and the vault tables built from it take the business entity’s name, not the source system’s. Do that and three tidy source models become one integrated data warehouse. Point a second feed at the model and the governed Customer already there is proposed as its match, for you to accept.

That’s why integration deserves more of your attention than the pipelines around it. Until 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.

An AI drafts the model and the mappings. You keep the calls that matter: which identifier wins, which system is the authoritative source for each attribute, which name is the preferred term and which are synonyms, and what the definition says when finance and support disagree.

That division of labor holds up as sources three, four, and five arrive. Choose an integration shape without a religion weighs four integration shapes, and each one still needs business keys someone ruled on.

Bring the business model in beside your sources, so neither side waits for the other. This week, take the Customer your three sources each store, decide which identifier wins, and write its definition down.

In DeltaVault, the AI business modeling workshop drafts the business model, and Map & Match proposes each table’s entity and each column’s attribute with a confidence score and a rationale.