“Raw” is the most misunderstood word in Data Vault. It describes the data, captured exactly as your sources delivered it, and it was never a description of the structure. Read it the wrong way and you get the wrong design, source tables mechanically decomposed into hubs, links, and satellites that mirror the systems they came from. The real modeling is still ahead of you, and you need a new plan for doing it.

An afternoon of generation is not integration

An entire category of source-driven Data Vault automation is built on the wrong approach. For twenty years this was treated as a rules problem: point a source-based wizard at a system and by the end of the afternoon it hands back something that looks like a Data Vault, with keys inferred from primary and foreign key constraints and load code generated from templates. Capture is fast, history is kept, the source is faithfully represented. Those are real virtues, but look at what they cost you.

AI coding agents with published Data Vault modeling skills mean you no longer need a licensed wizard to do this to yourself. Hand an agent a schema dump and within minutes you have hubs, links, satellites, hash key expressions, and load procedures that compile. The agent has done exactly what the rule engine did. It is the same afternoon of work the wizards sold, now generated in every terminal and every pull request, with fewer reviewers.

The trouble shows up on your second source.

  • The model dwarfs the estate it came from. Every source table has become three or four vault tables.
  • Keys stay source-shaped. Each hub keys on whatever its source happened to key on.
  • Meaning is missing. Nothing is classified or carries a business definition.
  • Systems stay strangers. Nothing lines up across systems.

Neither the wizard nor the agent can integrate, because integration is an agreement between systems and both of them met those systems one at a time. An agent cannot tell you that your sales platform’s CUST_NO and your billing platform’s ACCOUNT_ID are the same customer, because that fact lives in a decision someone has to make, not in either schema.

What that leaves you is not a Data Vault. It is your source systems, exploded in place at machine speed.

What does raw actually mean in a raw vault?

A raw vault definition has two halves: raw data, integrated by business key. A hub is a business key, and a business key is a decision about what the business counts: one Customer, no matter how many systems happen to store one. That decision is the entire point. It is why the oldest rule in the methodology says never model your vault on your source systems. Skip the decision and you are left performing the decomposition ritual without the reason for it.

This is where so many “failed” Data Vault projects actually went wrong. The model grew too bloated for anyone to read and tied back to no business meaning, while “integrate later” slid quietly downstream: first into the marts, then the dashboards, then every analyst’s Monday morning. The vault did not fail. It was never built in the first place.

The structure you own is a good staging layer

A source-shaped vault does one thing genuinely well: it captures every source faithfully and keeps the full history. That is not a vault, but it is exactly the job a persistent staging layer exists to do. Judge the structure as staging instead of as a vault and what you own turns out to be a working asset rather than a failed project.

So skip the teardown. Tearing it down buys you nothing, and it costs you both the history you already hold and the template-generated loads that keep that history current. Demote the structure to the job it is already doing, leave those loads running, and build the real vault above it. This time you start from the business, where business keys are decided rather than inferred from the constraints of a single system.

How DeltaVault models the business and loads the data raw

That rebuild is where DeltaVault earns its keep, and it begins with the modeling you skipped. A guided modeling workshop turns business stories into a business model. You describe how the business actually works in plain language, and the workshop proposes the concepts and relationships back to you, ready to review, rename, or reject.

Map & Match then connects your sources to that model. It proposes the business entity behind each table and the attribute each column maps to, and every suggestion arrives with a confidence score and a written rationale. Nothing changes until you accept it.

Once the mappings are agreed, the Data Vault accelerator builds the vault from your staging tables:

  • Designated business keys become hubs.
  • References become links.
  • Descriptive columns become satellites.

Every generated object is named for the business entity rather than the physical table. Accelerate the next source and the model accretes instead of duplicating, because the second system’s customers land on the Customer you already hold.

A derived business hub sits beside the raw hub it came from, its detail pane naming the raw object it derives from and the business key behind it

Derived objects say so. A business hub records the raw hub it came from and the business key it carries, so the line between what was loaded raw and what was computed on top stays readable months later.

So, how raw is your Data Vault? The healthy answer is that the data is entirely raw and the structure is not raw at all. If yours came out the other way around, nothing is wasted. The structure you own is your staging layer, and it is already built and loading. A source wizard bought you an afternoon and left the modeling undone. Give the workshop that same afternoon and build the vault you meant to have.