Third normal form and Data Vault wrote business meaning into the shape of the tables, because for decades only humans had to make sense of that meaning. Both are long-standing ways to design an enterprise data warehouse. In both, a customer gets its own table and every relationship becomes a join.
Now the question is whether AI needs meaning in the same form, and it doesn’t.
Meaning can move out of the table shapes into a description of the things your business runs on. That description says how each one is identified, how they relate and what describes them. Written down, that’s your business model. Written so a machine can read it, it’s an ontology, held in catalogs and metadata.
A lakehouse moves data from raw bronze through cleaned silver to report-ready gold. With the ontology written over the tables, the silver layer no longer needs a third normal form or Data Vault shape to carry meaning. It can stay thin and keep its sources’ shape. An AI agent reading the ontology works out which table, column and join a question needs.
We call this approach AIMS
We call this approach AIMS: AI-ready, Meaning-first Silver. Rather than restructuring source data to fit a predefined modeling methodology, AIMS starts with business meaning. That meaning is captured in governed metadata that people, AI agents and code generators can understand. The silver layer keeps the structure of its sources wherever practical. More integration comes in only when a specific business or technical requirement justifies it.
Each part of the name carries part of the argument.
- AI-ready. Business meaning is defined explicitly, so an AI agent can understand the data and use it.
- Meaning-first. The business things your data describes, how they relate and the columns everything depends on are defined and approved before a table publishes.
- Silver. The silver layer stays light and keeps the shape of its sources, with integration added only where it’s needed.
AIMS: Model the meaning. Preserve the source. Integrate by exception.
A row added, nothing retracted
Our first book, The Data Lakehouse for Everyone, stayed neutral on the silver layer’s shape. Its chapter on choosing an integration shape gave the shapes one table of factors instead of a verdict. This book keeps every factor and adds the row AI put into that table: what each shape leaves for a machine to read.
Where DeltaVault, our metadata catalog, already does part of AIMS, a closing “In DeltaVault today” section shows it on screen. Any part DeltaVault doesn’t do yet is the design of AIMS. DeltaVault and our AI agents never access your data, only the metadata provided.
Words used one way
Customer number 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. That system is the key’s record source.
The business model plus the mappings that tie silver columns to it is the meaning layer: how each row is identified and related, what each column and code means, which rules and history apply. The catalog’s summary of each table is that table’s data contract.
What’s left of data modeling? All of the deciding stays. None of the rebuilding does. You still decide what the business things are, what identifies each one, how they relate, what each column means and how much history to keep. But you stop restructuring every source table to carry them, and that’s just enough modeling.
Integration only when it’s needed
Traditional data warehouse approaches often require you to integrate data from different systems into a common structure before anyone can use it. That can involve considerable modeling, development and maintenance.
But what if you didn’t have to do all that work up front?
AIMS keeps data largely in its original source structure. It uses the ontology to describe what the data means and how it relates to other data. Extra integration structures come in only when there’s a clear reason for them.
For example, if two systems identify the same customer with different customer numbers, you can match those identifiers to one shared key. If someone needs one combined record for that customer, a golden record, you can add a view or table that brings the sources together. And if you need every historical change for auditing, you already have it: persistent staging in bronze keeps every version each source delivered, and silver reads from it.
The principle is simple: integrate when the requirement exists, not because a modeling methodology demands it. We call this integration by exception.
Tables are matched by meaning, records by a person
The ontology tells an AI agent that two systems’ customer tables hold the same kind of thing. So a question can cross both, and nobody builds a table to combine them first. But are two of those records the same customer? A person approves the match rules and types the rest, so nothing decides alone that two records are one customer. Either way, reports always get their own data marts.
One table and one example
Each argument closes on one table: the structural answer (what third normal form or Data Vault built, at what cost), what the agent reads, and what’s yours to decide.
In the worked example, an order management system knows Customer Account, Sales Order and its lines, Product and Order Status. A sales system knows the same Customer Account under its own key, with its Country. It’s a composite built for this book, not a case study.
Where should you start?
Start with Meaning used to live in the tables if you learned your craft on Data Vault or third normal form. If you lead a data platform, start with The economics of meaning flipped. If you build the silver layer, read the first three chapters, then The business model is the ontology through Integration by exception. Read The agent reads the contract if somebody asks what “AI-ready” means. And end on Seven steps to a meaning layer, steps you can start on Monday.