“Raw” is the most misunderstood word in Data Vault. It describes the data, captured exactly as your sources delivered it, never 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 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. Its keys are inferred from primary and foreign key constraints, and its load code comes 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 did exactly what the rule engine did. It’s 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 met those systems one at a time. An agent can’t tell you that your sales platform’s CUST_NO and your billing platform’s ACCOUNT_ID are the same customer. That fact lives in a decision someone has to make, not in either schema.

What that leaves you isn’t a Data Vault. It’s 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 no schema can make for you. That decision is the entire point. It’s why the oldest rule in the methodology says never model your vault on your source systems. Skip the decision and you’re performing the decomposition ritual without the reason for it.

So many “failed” Data Vault projects went wrong right here. The model grew too bloated for anyone to read and tied back to no business meaning. Meanwhile “integrate later” slid quietly downstream: first into the marts, then the dashboards, then every analyst’s Monday morning. The vault didn’t fail. It was never built.

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 isn’t a vault, but it’s exactly the job a persistent staging layer exists to do. Judge the structure as staging instead of as a vault and what you own is a working asset rather than a failed project.

So what do you do with it? Skip the teardown. It 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’s 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 one system’s constraints.

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. An AI business modeling workshop turns business stories into a business model. You describe how the business actually works in plain language. 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. 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, and here those are the hubs, links, and satellites you demoted, still loading, their history intact:

  • 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. The raw hub in the picture is one the accelerator built, and the business hub beside it records the raw hub it came from and the business key it carries. 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 isn’t raw at all. If yours came out the other way around, nothing is wasted. The structure you own is your staging layer, and it’s 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.