If you can design a Data Vault, you already hold the scarcest modeling skill an AI-ready data architecture needs. What you can stop doing is building the tables.

When we argued that you don’t need Data Vault anymore, the sharpest pushback came from the people who build vaults for a living. Four of their points deserve a full answer, because each one is mostly right.

Meaning needs no tables; history still does, just not vault tables

One reader put it plainly: Data Vault addresses integration, history and traceability, while an ontology represents business meaning. So why would better query accuracy from an AI retire the first because of the second?

The answer is that a vault did two jobs at once, and a 2026 text-to-SQL experiment by Daniel Su and colleagues bears on only one of them. The researchers held the questions and data fixed and varied only structure and naming. Descriptive names made up for missing structure, but added structure never made up for opaque names. That result matters because much of a vault’s structure exists to carry meaning. A hub says “this is a core business concept, and this key identifies one instance of it.” The vault said so in structure because in 2005 a model’s readers (a load pattern, a query optimizer and a reporting tool) could read a table and nothing else.

An agent can read that statement directly, so the meaning no longer has to be encoded as structure.

The vault’s other job stays, but it no longer needs the vault’s tables. Traceability and history live in bronze, where persistent staging keeps every version each source delivered, insert-only and in the source’s shape. Integration keeps the vault’s identity discipline of one business key per record source, and it happens by exception: you are lazy about rebuilding tables and eager about recording meaning. You define keys, roles and attribute mappings first, so a question can cross two systems before anyone builds a combined table. When a business requirement calls for a shared key and a golden record, you add them beside the source tables, and nothing underneath them changes. That approach is AIMS, short for AI-ready, Meaning-first Silver: model the meaning, preserve the source, integrate by exception.

Where does the business meaning come from?

The same reader then pressed the point that matters most. An AI can infer relationships from source data, but the right business context comes only from engaging the business, and a model can be technically correct without being the right model for the business. A second reader added that the vaults that turn out well are designed top-down, starting from business language, concepts and domains.

Both readers are right. In data modeling for AI, the model’s reader is an agent that takes every definition at face value, so the business meaning has to come from the business and be written down, not left for the agent to infer from structure. That’s why AIMS starts with a business modeling workshop with your business expert, held before anyone maps a single column. The workshop starts with business stories, moves to the things those stories name, and then works out their relationships, attributes and keys. John Giles has long insisted that a vault starts in precisely that place, and the progression he teaches is Ensemble Logical Modeling. Ensemble Logical Modeling is a top-down way to model the business before the tables: it names the business concepts, their relationships and the keys that identify them, which is the same content an ontology records. In AIMS, its top-down model is a deliverable in its own right. Once you write down what each attribute means, in a form a machine can read, that model becomes a business ontology.

The AI takes over from there and writes the first draft of the meaning layer, working from each table’s profile and the mappings you’ve already approved. A person still approves every decision that changes meaning or values, such as what a business key really identifies, whether the customers in two systems are the same customers, and how much history a table keeps.

The decision-making never left the room. It carries more weight now than it did before, because an agent will read a wrong definition with full confidence and apply it at scale.

The semantic layer is an umbrella, not a gate

A semantic layer, the second reader wrote, isn’t a gate or a filter that sits between raw, curated and consumed data. It’s an umbrella, defined end to end, that supplies context to every pipeline as data moves from source through landing and persistent staging and on to the raw vault, the business vault and the marts. That reader has built exactly that overlay for Data Vault.

In AIMS, the meaning layer does the same job, and the semantic layer is what you render from it, one per platform. You write the model first, before any data lands and independent of any platform, and templates then generate the tables, loads and tests from the approved metadata. Every statement you record about a table rolls up into a summary, and that summary becomes the table’s data contract. The contract is the briefing an agent reads, and it is also the source you render each platform’s semantic layer from. Where we part ways is over what sits under the umbrella. Once the umbrella carries the meaning, a raw vault and a business vault beneath it encode that same meaning a second time, as structure. So keep bronze and keep the marts, and let silver preserve each source’s shape, one table per source table, with the meaning written over it.

Where Data Vault 2.0’s architecture, methodology and model live now

The second reader’s last point was that Data Vault 2.0 is an architecture, a methodology and a model, and that our case against it took on only the model. That’s a fair challenge, so here is where each of those pillars lives now.

  • The architecture bought you auditability of every version, parallel loads and the ability to add a source without altering what’s already there. Persistent staging delivers all three in bronze, and the marts stay exactly where they are.
  • The methodology keeps its repeatable part intact. Templates build the tables, loads and tests from approved metadata, and one business area finishes before the next one starts.
  • The model carries over one construct at a time. A hub becomes a business entity and a view of its keys, and a link becomes a relationship with its role and cardinality. A satellite stays as one unsplit table per source table, with what each column means written down.

The business vault becomes integration by exception: you add a shared key and a golden record beside the source tables when a business requirement calls for them. What a hub becomes when an agent reads the model walks through each construct in turn.

People who hold the vault discipline are the scarcest skill pool of any integration shape. An AI-ready silver layer also depends on that discipline more than any other shape does, and that weighs heavily when choosing an integration shape.

Test whether your vault model is ready for an AI agent

  1. Run your next business modeling workshop the way you always have: top-down, with your business expert in the room, starting from business stories and working toward the things those stories name.
  2. Capture the whiteboard as written statements beside each source table. For each table, record what one row represents, its business key and the record source that issues it, each relationship with its role and cardinality, what each column means, and how much history the table keeps.
  3. Don’t build a hub. Put those statements in front of an agent instead, ask it a question that crosses two source tables, and note which parts it answers and which it declines.

If the statements hold everything the vault held, you haven’t unlearned anything. You’ve only stopped paying to encode the same meaning a second time, as structure.

In DeltaVault, the business model you draw on the canvas is the same metadata its AI reads. For teams that still want a Data Vault, DeltaVault models one.