In this chapter
- A Data Vault diagram is a paragraph. Read aloud, its tables are sentences about your business.
- The readers set the limits. Tables were all a machine could read, so meaning went into tables.
- The bill is the price of the encoding. What it bought, and the one change that brings it down.
The methods put business meaning in the tables because nothing else could read it. Now something can.
That’s a claim about methods you may have built a career on, so it has to be earned. Third normal form and Data Vault aren’t the villains of this story. They’re the most disciplined answers anyone gave to a real problem, and the problem hasn’t gone away.
What changed is who, or what, can read the answer.
The hub is a sentence
A Data Vault model is built from three kinds of table: hubs, links and satellites. Read a Data Vault diagram aloud instead of looking at it. A hub says, “This is a core business concept, and this is the key that identifies one instance of it.” A link says, “These two concepts relate, and this is the role each plays in the relationship.” And a satellite says, “These attributes describe that concept, as this source system saw them, 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.
A canonical third normal form warehouse is a longer paragraph with stricter grammar. Every concept has one definition and one owner. Any source that knows about a customer gets bent into the one shape the model allows. Inmon’s definition of the warehouse, in Building the Data Warehouse, carries the grammar in four adjectives: subject-oriented, integrated, time-variant, non-volatile. Three of the four are statements about meaning. Only one is about storage.
Read this way, both methods are ontologies. They name the things your business runs on and say how each is identified, how they relate and which attributes describe them. And they write it all in table structure, because when they were designed, nothing else could hold meaning and still do work.
Figure 1.1: the hub is a sentence. Each table kind beside the sentence it encodes, and on the right the same sentences written once as catalog metadata.The methods were right, for the readers they had
Who read a data model in 1995, or 2005, or honestly 2015? A load pattern read it. It had to know which column was the key, which table owned the history and which row was current. A query optimizer read it too. So did a reporting tool, through a layer of business names and measures that somebody built by hand on top, a semantic model.
Every one of those readers could consume a table. Not one could consume a glossary entry, a written definition or a mapping spreadsheet. So if you wanted a machine to use your meaning, you had one option: make it structural.
That’s what the methods did, deliberately and well. Linstedt described the Data Vault in 2002 as “a detail oriented, historical tracking and uniquely linked set of normalized tables.” Each design choice makes a fact about the business survive inside a table where a load could find it.
Here’s the tell that the readers, not the authors, set the limits. Both canons give metadata a chapter, and both treat it as documentation that sits beside the system. Neither says “and the system executes this,” because no system could. The meaning that mattered at run time had already been poured into the tables. The metadata was the commentary.
A Data Vault author says the same from inside the method. In a vault, Patrick Cuba writes, “hub tables are the nodes reserved for business entities”. Links are its edges, he says, and satellites are their properties. Cuba adds that “what a traditional Data Vault lacks are explicit, machine-understandable semantics”. The meaning is there, written as structure. Nothing but a table could carry it to a machine.
Metadata-driven automation arrived later and seems to contradict this. Teams generated their vaults from mapping sheets for a decade. But the sheet told a generator which hubs and satellites to build, and every consumer read those tables. The automation shortened the build. It never moved the meaning, because the readers downstream still couldn’t read anything else.
The bill is the price of the encoding
Once you see the methods as meaning written in structure, their cost stops looking like overhead. It looks like an invoice, itemized by unit of meaning.
A concept costs a table, and each fact about it costs another. Andrew Foad created a lighter approach that keeps each source table whole, the Hook method. He reports from his own team: “Our single ingested table eventually blew out to ten tables for Data Vault.” Ten tables isn’t waste. It’s one source table’s worth of your meaning, written out in full.
Reading it back pays the encoding again. In Foad’s worked comparison, a two-table join over data kept in its source’s shape is a four-table join in the vault. Real questions are wider than that. So a vault adds two more kinds of table. One lines up the version of each record in effect on a date, a point-in-time table. The other pre-joins hubs and links along a common query path, a bridge table. A 2026 industry analysis says the hub-link-satellite structure “requires assembling data through multiple joins before it resembles anything analytically useful.”
A canonical definition costs the analysis before anything ships. Nothing can be loaded until the one shape is agreed. So the slowest conversation in your company sets the delivery date of your fastest pipeline.
A change to the meaning is a migration of the structure. What happens when your business decides that a customer account and a billing account are different things after all? A vault adds hubs and reroutes links and satellites. A canonical model reopens the agreement.
None of these line items is a mistake. Each is the honest cost of making a sentence about the business executable when only tables could be executed.
What the bill bought, and what we keep
It would be cheap, and wrong, to stop here and call the methods expensive. The bill bought auditability of every version a source ever sent. It bought parallel loading, because hubs, links and satellites don’t depend on each other at load time. It let you add a source without altering what was already there. And applications that can’t afford to learn each source’s quirks got a stable, source-independent interface.
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. Persistent staging, the layer below silver that keeps every version a source delivered, already does it in bronze, insert-only and in the source’s shape. It loads one table per source table, in parallel, and a new source adds without altering anything. A stable interface is a golden record, one combined view or table built when someone asks for it.
AIMS (AI-ready, Meaning-first Silver) also keeps the discipline the methods taught: identity first, relationships explicit with their roles, history chosen on purpose per table, nothing dropped silently. Nothing in this book calls a method obsolete.
What changes is the default, and where the meaning lives.
What changed to make data modeling for AI possible?
For the bill to come down, one thing had to become true. A machine had to read a sentence about the business without that sentence being a table.
It can now.
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,” and “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.
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.”
Once a sentence can be read as a sentence, it no longer has to be written as a table. The meaning can move into a governed store of metadata that describes your data, a catalog, where it’s cheap to add and cheap to change. A person, an AI agent and the generator that turns metadata into tables and loads (a template engine) all read it there.
So the tables can stay the shape of the source.
| The structural answer | A vault builds five or six tables for one Customer Account in two systems, four of them before the first report, where the catalog holds one entity, each key with the system that issued it, and a match rule tying both keys to one. |
| What the agent reads | The three sentences the vault encoded become three lines of metadata: the entity with its business key and record source, the relationship with its role, and the attribute tied to its column. |
| Yours to decide | Nothing yet: the first decision, the one both methods put first, is what the business things are and what identifies each one. |