Most data platforms lose the business somewhere between the definition and the table. The definition lives in a catalog, the structure in a modeling tool, the lineage in a third application, and the implementation in source control. Every handoff between them leaks a little meaning and a little accountability.

By the time the pipeline runs, the Customer your stakeholders agreed on and the customer hub your engineers loaded are related by folklore. Earlier posts in the how we use AI series guard the business side: business context is a governed setting that every AI skill reads, and the modeling workshop writes nothing until you apply.

This post takes the next step. Approved meaning becomes a technical data model, a Data Vault or a dimensional model, and lands inside a medallion architecture with its bronze, silver, and gold layers without losing itself on the way.

Why does meaning drift between the business model and the warehouse?

Meaning drifts because the tools never share a record. Your glossary entry is a paragraph in one product. The hub is a box in another. The lineage graph is harvested after the fact from query logs by a third, and the load code sits in a repository that knows nothing about any of them.

Every translation between those four artifacts is done by a person working under a deadline. Each handoff is another chance to drop a qualifier, rename a key, or lose the reason a satellite was split in the first place.

Accountability drifts along the same path. The mapping from a source column to a business attribute was approved once. But where does that approval live? It’s in an email thread, so nobody can say whether it survived the last source change. This isn’t a problem of careless people.

The meaning simply has no medium that survives the handoff.

How DeltaVault keeps the business attached to the technical data model

DeltaVault keeps business and technical metadata in one record. Definitions, structures, mappings, and lineage live on one branch, get reviewed on one commit screen, and land in Git as readable YAML. Three moves build the technical model on top of the business one. Each of them writes back to that same record.

The structures are visible and reviewable, not implied by code

Data Vault modeling starts with a right-click on a staging table. The accelerator, a deterministic engine, decomposes that table into hubs, links, and satellites on a canvas inside the catalog. From there you unify links, split satellites, and reclassify until the shape is right. A dimensional model gets its own star-schema canvas, and the workspace canvas lays your layers out along the dependency graph.

Nothing physical exists until you materialize. Materialization runs through the same review-and-diff step as every other change, so every structural decision ends up as a diff someone actually read.

The model is a working surface, not a picture beside the warehouse.

AI does the repetitive parts, and every proposal stays inspectable

AI skills take the rote work on those canvases: a view asked for in plain language, keys and relationships discovered across the tables you select, and drafted descriptions and business names. None of it writes to the catalog until you accept, and an accepted write goes through the same role checks and audit trail as a human edit.

What stays on your desk is judging the proposal, not typing the answer. Where the source doesn’t hold the model’s shape, discovered relationships and drafted views build the bridge.

Map & Match ties every table and column back to approved meaning

The third move is what keeps the business attached. Map & Match proposes which business entity each source table represents and which attribute each column maps to, and nothing changes until a person accepts it. Once a table is linked, the entity’s name becomes its business name downstream. So the accelerator names the hub from Customer rather than from whatever the source system happened to call the table.

Lineage rides the same record. Click a column on the Lineage tab and its whole path lights up, every ancestor and every descendant, across as many hops as the pipeline has. That works because every derived column records which source columns feed it. Column-level lineage is written when the mapping is made, never reconstructed during an incident.

The result is a contract, not a diagram

Put the three moves together and what do you hold? It isn’t a picture of the warehouse. It’s a governed generation contract, with business meaning, technical structures, mappings, and approved decisions gathered into one reviewed record.

The template engine reads that record directly and renders the create-table statements and load code for Databricks, Snowflake, or Microsoft Fabric. When a mapping or a definition matters enough to enforce, an administrator can set a gate that blocks a build until it’s complete.

So the Customer in the glossary and the customer hub in the vault stop being related by folklore. They’re related by a mapping someone accepted, a structure someone reviewed, and a lineage edge nobody had to draw. To watch the generation contract form on your own metadata:

  1. Link one source table to the entity it means from its Details tab, or let Map & Match propose the link.
  2. Accelerate a Data Vault from its staging table and watch the hubs take the business name you approved.
  3. Open the Lineage tab, click any column, and follow its path back to the source.