Your data model has a new reader, and it reads sentences. Once a machine can read a sentence about your business, every benefit Data Vault’s tables bought you has a cheaper home.

Third normal form and Data Vault wrote business meaning into table structure because, for decades, a table was all a machine could read. For those readers, the methods were right.

So what changes when the reader does?

A machine can read the sentence now

Take four sentences about a business. A model can read “Customer Account is identified by company code and customer number in the order system,” and “Sales Order refers to Customer Account as sold-to and again as bill-to.” It can read “Status code C means Cancelled in this system,” and “One row is one Sales Order version.”

Having read them, it can propose which column carries which meaning, generate the load and answer the question. Say you ask how many orders a customer was billed for, not counting cancellations. The model can follow bill-to rather than sold-to and match on company code and customer number. It can read status C as a cancellation and count each order once, not once per version. Nobody had to turn those sentences into tables first.

Databricks, introducing the data ontology, names why that matters now. With AI agents, it says, “there may be no knowledgeable human sitting between the data and the decision. The agent has to discover the meaning itself.”

That changes what metadata is for. The classic texts of both methods give metadata a chapter. But both treat it as documentation that sits beside the system. Even a mapping sheet that generated a vault only told the generator which tables to make.

Now the sentence itself gets read. The metadata stops being commentary and becomes the model. It can live in a governed store of metadata that describes your data, a catalog, where it’s cheap to add and cheap to change.

Where do Data Vault’s benefits live now?

None of this makes the old structure a waste. It bought four things you still need. But not one of the four needs your meaning written as tables. So each now has a home that costs less.

A lakehouse moves data from raw bronze through cleaned silver to report-ready gold. An auditor wants to see what each source said, and when. So a store in bronze keeps every version a source delivered, insert-only and in the source’s shape, and that’s persistent staging.

Some applications can’t afford to learn each source’s quirks. One combined view or table, built when someone asks for it, gives them a shape that doesn’t move, and that’s a golden record.

Here’s where each benefit goes.

  • Every version a source ever sent. Persistent staging keeps it, so audit needs no vault.
  • Loading in parallel. A vault’s tables don’t wait on each other at load time. Persistent staging loads one table per source table, and those don’t wait either.
  • A new source without altering what’s there. A vault adds tables beside the old ones. Persistent staging does the same, and the catalog gains a few new sentences.
  • A stable interface. A golden record gives one to the applications that need it, and only to them.

As we put it in “How raw is your Data Vault?”, “A source-shaped vault does one thing genuinely well: it captures every source faithfully and keeps the full history.” That one thing no longer needs a vault.

Integration comes in with the stable interface, and it waits for a reason. Two systems may number the same customer differently. One key that connects those identifiers, a shared key, gets added only when a specific business requirement calls for one. The golden record waits the same way. Integrating when the requirement exists, not because a method demands it, is integration by exception.

Data modeling for AI is writing the sentence well

So is there any modeling left? All of the deciding is: identity first, relationships explicit with their roles, history chosen on purpose per table and nothing dropped silently.

Only the form changes. Each decision becomes a sentence in the catalog. A person reads it there, and so do an AI agent and the generator that builds your tables and their loads. The silver tables keep the shape of their sources.

Identity first shows what a good sentence needs. Customer 123 in your order system and customer 123 in your sales system can be two different customers. A key only means something inside the system that issued it. So the sentence names the columns that identify one customer, the business key, and the system that issued them, the record source.

Restructuring every source table so a machine can find its meaning is work the new reader doesn’t need. We call the approach that skips it AIMS, short for AI-ready, Meaning-first Silver. Write down the business things your data describes, how each is identified and how they relate, and you have your business model. That model plus the mappings that tie each silver column to it is the meaning layer.

You make every decision the methods demanded and none of the rebuilding. That’s just enough modeling.

Sort the reasons your tables exist

  1. Open the last vault or warehouse design you reviewed.
  2. Write the reason each table exists beside it.
  3. Mark every reason that comes down to history, parallel loading, a new source or a stable interface. Each of those now has a cheaper home in persistent staging or a golden record.

What’s left is mostly meaning. It belongs in the meaning layer, as sentences your agents can read. Write those sentences before you design another table.