You don’t need Data Vault in your lakehouse. You don’t need third normal form in your silver layer either, and reshaping every source table into hubs, links and satellites, or into one canonical model, is now work you do for nobody.

That’s hard to hear if you built a career on those methods. So here’s the case, and here’s the part of your craft that matters more than ever.

Our first book, The Data Lakehouse for Everyone, refused to pick a side and handed you a table of factors instead of a verdict. AI added a row to that table: what each shape leaves for a machine to read. That row decides it, so this time we’re picking one.

Meaning went into tables because nothing else could read it

Read a Data Vault diagram aloud. A hub says, “This is a business concept, and this key identifies one.” A link says, “These concepts relate, in this role.” A satellite says, “This describes it, as this source saw it, as of this load.”

The diagram isn’t a picture of tables. It’s a paragraph about your business, written in the only language a database could execute. Third normal form is the same paragraph with stricter grammar, every source bent into one agreed shape.

Why write meaning as structure? In 2005 the readers of a data model were a load pattern, a query optimizer and a reporting tool. Every one could read a table. None could read a glossary entry. If you wanted a machine to use your meaning, you made it structural.

The methods were right, for the readers they had.

The bill was the price of that encoding

Seen that way, their cost reads like an invoice. Andrew Foad, who created the lighter Hook method, reported from his own team: “Our single ingested table eventually blew out to ten tables for Data Vault.”

A canonical model can’t load anything until the one shape is agreed, so the slowest conversation in your company sets the date of your fastest pipeline. And when the business changes its mind about what a customer is, you migrate structure.

None of that was a mistake. It was the honest cost of making a sentence about your business executable when only tables could execute.

Now the machine reads the sentence

That constraint is gone.

A model can read “Customer Account is identified by company code and customer number in the order system” as a sentence, without anyone pouring it into a hub first.

In 2023, Sequeda, Allemang and Jacob asked a large language model business questions over an enterprise database. Against the raw schema, it was right 16 percent of the time. Over a description written for a machine of what the business things are, how each is identified and how they relate (an ontology of the same tables), it was right 54 percent of the time.

Gartner’s May 2026 release put it flatly: “Traditional schema-based data models alone no longer suffice for agentic AI because they lack business context and data meaning.” Every major platform’s new semantic layer sits over the tables you already have.

So who builds the physical data model now?

Nobody designs it by hand anymore. Your silver tables keep the shape of their sources. So there’s no new structure left to invent. In this approach, the AI drafts the mapping from each column to the meaning it carries. A person approves every decision that changes meaning or values. Templates generate the tables, loads and tests from the approved metadata, and no model guesses at run time.

Isn’t that just a rename pass, source tables with friendlier names? It isn’t. A rename pass skips the decisions. Here every one is made and written down, as metadata instead of as tables.

What about history and audit? The raw layer, bronze, already keeps every version each source delivered, in the source’s shape. That’s persistent staging.

What about the customer who lives in two systems under two numbers? You add a shared key when a real business requirement asks for one, and a golden record when someone needs one combined view. That’s integration by exception, not integration as a tax on every table.

We call the whole approach AIMS, short for AI-ready, Meaning-first Silver. Model the meaning, preserve the source, and integrate by exception.

Designing hubs, links and satellites by hand was a real skill. In AIMS there’s no vault to draw, and the tables you do get are generated.

The modeling that’s left is the hard part

Here’s where we agree with every good Data Vault practitioner. The principles were never the tables.

What’s left of data modeling for AI? It’s all of the deciding. You still decide what the business things are and what identifies each one. And you still decide how they relate and in what role, what each column means and how much history each table keeps. Written down, that’s your business model. Written so a machine can read it, it’s an ontology.

And it got harder, not easier. A wrong hub used to sit quietly in a diagram. A wrong definition in an ontology gets read, confidently and at scale, by every agent that answers a question. So the modelers who understand why a business key matters are the people this era needs most. AI took the building. It can’t take the deciding, and it reads every decision you make.

Try it on one table

  1. Pick one source table your team would split into hubs, links and satellites.
  2. Write its sentences instead: what one row is, what identifies it and in which system, which relationships it carries, and what each column means.
  3. Ask what the ten tables would give you that those sentences, persistent staging and a generator don’t.

If you can name something, say so wherever you found this post. That’s the argument worth having.

The whole case is in our second book, AIMS: Rethinking the Lakehouse Silver Layer, free and open on the site.