• Every step of a Data Vault build has a counterpart that produces a statement instead of a table.
  • Each source table gets one silver table at the same grain, and the raw vault and the business vault become statements in the model instead of tables.
  • Nothing hashes the business key, so every key carries its record source in plain text.
  • You build no point-in-time or bridge tables in silver, because the agent joins along each relationship’s role and cardinality.
  • The AI does most of the hours of work, and a person makes the decisions that carry the risk.

If your team’s muscle memory is Data Vault, you already know the sequence for building an AI-ready silver layer, one that an agent can read.

You write the meaning as a model beside silver tables that keep their source’s shape. The AI drafts the model, and a person approves it. That model, together with the mappings that tie each column to it, is the meaning layer. We call this approach AIMS, short for AI-ready, Meaning-first Silver. Seven steps to a meaning layer walks through the general sequence. This article maps each of those steps to the Data Vault step you already know.

Start where a vault starts: the business concepts

Run the business modeling workshop for one business area, with your business expert in the room. Each business entity, a thing your data is about, gets a definition and a draft of its grain sentence, which states what one row of its table means. Together they guard against the undefined noun, where three systems say “customer” and mean an account, a person and a billing party.

You don’t pick a table type in the workshop. An entity’s class sets how its rows are told apart and how much history its table keeps by default, and the class follows from the model:

  • Event: something that happens.
  • Association: a relationship.
  • Independent: a thing that stands on its own.

A hub is an independent entity.

Keep every source table whole on persistent staging

Your engineers profile the business area’s source tables. Each source table gets one silver table at the same grain, with its columns typed and renamed. By default, that silver table is a view over persistent staging, the layer below silver that keeps every version a source delivered, insert-only and in the source’s shape. Persistent staging is where the audit trail a vault promises lives. It stays as bronze, the marts stay as gold, and the raw vault and the business vault become the model.

Write the hub’s key so a person can read it

For each entity and each record source, the AI proposes a business key: its parts, in order. You approve that key along with its history and delete policies. One customer’s key reads awlt||AU||00001042: awlt is the record source code for the order system, AU is the company code and 00001042 is the customer number.

Data Vault calls a prefix like that the business key collision code, and a vault hashes the result. Here nothing hashes the key, so every key carries its record source in plain text. A person can read it in a query result, and an agent can read it with nobody beside it to explain. The hub becomes the entity’s key register, holding every business key the entity has. What a hub becomes when an agent reads the model translates every other construct.

Every reference between entities gets a role, a cardinality and a policy for when it doesn’t resolve. That policy defaults to Warn, because a row that arrives before the row it references is normal in a lakehouse. Each role gets its own key column on the referencing table, so sold-to customer and bill-to customer become two named relationships instead of two foreign keys you have to guess between. A hierarchical link becomes the parent’s key column and one hierarchy relationship.

Map the satellite’s columns, critical ones first

Instead of landing every column in a satellite and defining it later, you start with the columns that:

  • identify
  • relate
  • hold a code
  • are sensitive

Each maps to a business attribute that names what kind of value the column holds (its semantic type) and its unit or currency. A code column gets its code list and an approved code mapping, so the order system’s C means Canceled.

The AI drafts each mapping from the table’s profile and from the mappings you’ve approved on sibling tables. You then map every other column or mark it source-only. That coverage is measured, but it is never a gate.

Each table gets one history policy (append, current, versioned or snapshot), which replaces the satellite’s load date and the type 2 pattern. The AI proposes the policy with a reason, and you confirm it.

Publish the contract instead of a point-in-time table

Everything above projects into one document per table, its data contract, which runs from the grain sentence to the known limitations, including the unmapped columns and codes. Publishing is a review of that document, and a person makes the call. A table whose contract passes that review counts toward the silver layer, and gold may read from it.

In AIMS, you build no point-in-time or bridge tables in silver. The agent joins along each relationship’s role and cardinality and reads each table’s versions through its history policy. When a source changes shape, the change shows up as a contract diff for you to review.

Leave the business vault for a requirement

When do two systems’ customers join? They don’t, until someone needs them joined. Say finance asks for one customer list. An exact-match rule on tax number, once a person approves it, gives both customers one shared key on the entity’s key register. A golden record beside it carries a survivorship rule per attribute, which decides whose value wins. That’s the business hub and the business satellite, built by exception.

Then point an agent at the data contract, with instruction lines rendered from it: read the grain sentence first, and decline any clause of a question that has no mapping behind it. You’re done when the agent’s answer cites the contract and declines the clause it can’t answer.

What the AI drafts and what a person approves

The AI does most of the hours of work:

  • profiling the source tables
  • proposing business keys
  • drafting grain sentences, mappings and history policies

A person makes the decisions that carry the risk: identity, equivalence, history and anything that changes a value. Templates then build the tables and loads from the approved metadata, so no model guesses at run time.

In a hand-built vault, a finished hub teaches the next hub nothing. Here, every approval becomes the demonstration behind the next suggestion, so the business keys and mappings you approve on one table shape the drafts for its siblings.

Four levels a table climbs, one business area at a time

A table climbs four levels as its statements are written:

  • Identified: an agent can count its rows.
  • Related: it can join safely.
  • Described: it can compare values.
  • Integrated: it gives one answer per customer across systems.

Which level is enough depends on the business area, and you settle it with evidence instead of debate. Keep a set of business questions with checked answers, including one the agent should decline, and run that set each time a table climbs a level. When the answers come back right and the agent declines the question it should, the table has reached the level its business area needs.

At every level, you can also see which statements a person has decided. In DeltaVault, a value the AI proposed keeps its AI badge, with the model’s confidence and rationale, until a person edits it.