What a hub becomes when an agent reads the model
Every silver layer method answers the same few questions. What is the business thing, how do you tell one from another, which system issued its key, and how does it relate to the others?
Third normal form and Data Vault answer by building tables. A third way keeps each table in its source’s shape and writes the answers down beside it, in a model of the business that an AI agent reads. That’s AIMS, short for AI-ready, Meaning-first Silver. The agent reads that model table by table, through a summary of everything written down about each table, its data contract.
So a hub, a link or a same-as link stops being a table you build. It becomes a statement in that model.
Where does each method keep the meaning?
- Third normal form keeps it in one canonical model. Bill Inmon’s integrated warehouse gives every concept one definition and one owner, then bends every source into that shape.
- Data Vault splits it across table types. Dan Linstedt’s hubs carry business keys, links carry relationships and satellites carry context. The split costs several tables per source table.
- AIMS writes it beside the source. Each source table becomes one table at the same grain, typed and renamed. The meaning lives in the business model.
Why did meaning go into tables at all? For decades a table was the only thing a machine could read. A load pattern, a query optimizer and a reporting tool could each read a table. But none of them could read a written definition. That’s changed, and You don’t need Data Vault anymore makes the case in full. And only the costliest method, the canonical model, says what each column means, by rewriting every source. Every method stops at the concept measures that gap pattern by pattern.
Sixteen tables, seven or four for the same two systems
Take an order system and a sales system that both hold customers. Each system has a short code that every key it issues carries. The code is awlt for the order system and wb for the sales system. The order system holds customers, order headers and order lines. The sales system holds accounts.
That’s the worked example of the AIMS book, AIMS: Rethinking the Lakehouse Silver Layer, with one column added. The order system’s customers carry a parent customer number, so there’s a hierarchy to translate. The book’s example has none.
Here’s what each method builds for it.
| Method | Tables | What they are |
|---|---|---|
| Data Vault | 16 | 3 hubs, 4 links, 5 satellites and a reference table, then a business satellite, a point-in-time table and a bridge |
| Third normal form | 7 | 4 entity tables, a key cross-reference table and 2 lookup tables |
| AIMS | 4 | One per source table, kept in its shape, plus 3 views that list each entity’s keys |
AIMS adds a shared key and a golden record only when a business requirement asks for them. Until one does, the two systems’ customers stay apart.
A relationship you write down instead of build
Here’s one relationship translated whole: a customer’s parent account.
Data Vault builds a table for it, a hierarchical link. The link pairs each customer’s hash key with its parent’s. Third normal form adds a self-referencing foreign key to the customer table.
AIMS adds a column too, the parent’s business key column on the customer’s table. Then it writes the rest down in the business model, as a hierarchy relationship from Customer Account to itself:
- Role: parent account.
- Cardinality: many-to-one.
- Optional: yes, so a customer may have no parent.
- A parent that isn’t found: warned and flagged.
An agent reading the table’s data contract joins only along relationships like this one, by role, and names any join that changes the grain.
The two sections below translate the rest, one for each method you might be coming from. Every AIMS term in them is defined in a sentence or two, problem first, in the book’s glossary and reference tables.
From Data Vault: most tables become a statement
How do you tell one customer from another, or one order line from the next? Data Vault answers with a table type. AIMS answers with one of five entity classes on the business entity: independent, dependent, event, reference or association. The class says how the entity’s rows are told apart and how much history its table keeps by default. A hub is an independent entity.
Data Vault integrates in the raw vault, by business key, and conforms values later in the business vault. AIMS integrates by exception. Two systems’ records never join until a business requirement calls for a shared key.
| In Data Vault you build | In AIMS |
|---|---|
| A hub per core business concept | No table. An independent business entity in the model, and a view of its distinct keys |
| A hash key | A readable business key, such as awlt||AU||00001042, led by the code of the system that issued it |
| A satellite per source | No split. The source-shaped table keeps its columns, and mappings in the model tie them to their meaning |
| A link | No table. The other entity’s business key column, and one relationship in the model with its role and cardinality |
| A hierarchical link | No table. The parent’s business key column, and one hierarchy relationship |
| A same-as link | No table. A shared key in the view of the entity’s keys, added only when a requirement asks |
| A reference table | A code list, with the mapped value beside each source code |
| A business hub and business satellite | A golden record, built only when a requirement asks |
| Point-in-time and bridge tables | Nothing in silver. The agent joins along the relationships and reads each table’s versions |
Effectivity, multi-active and status tracking satellites and ghost records go the same way. Each becomes a policy or a sentence in the model, not another table.
From third normal form: integrate when asked, not up front
Third normal form integrates up front. Every source is rewritten into one canonical model before anything ships. AIMS keeps each source in its shape and writes the canonical model’s definitions down beside it instead.
| In third normal form you build | In AIMS |
|---|---|
| One canonical table per entity, every source rewritten into it | One table per source table, kept in its shape, with the entity defined once in the model |
| A surrogate primary key | A readable business key, with no surrogate |
| A key cross-reference table | No table. A shared key in the view of the entity’s keys, added only when a requirement asks |
| A foreign key | The referenced entity’s business key column, and one relationship in the model with its role and cardinality |
| A self-referencing foreign key | The parent’s business key column, and one hierarchy relationship |
| A lookup table | A code list, with the mapped value beside each source code |
| Supertype and subtype tables | No tables. The model says one entity is a kind of another |
| Effective dates, designed table by table | A history policy per table: append, current, versioned or snapshot |
| The integrated row | A golden record, built only when a requirement asks |
| A data dictionary | The business model itself, which the agent reads |
The canonical model’s best idea, one definition for each concept, stays. What goes is bending every source to fit it.
Start with the construct you’d defend hardest
You don’t have to translate a whole model to test this. Take the construct your team would argue for longest and work one table through it.
- Pick one table from your current model and find each construct it uses in the tables above.
- Write its AIMS statements: the business key and its record source, and each relationship with its role and cardinality. Its entity class follows from the model.
- Mark what waits for a business requirement, the shared key and the golden record, and leave it unbuilt until one asks.
If the statements hold everything the construct held, you’ve translated it. If they don’t, that row is the one to argue about.
DeltaVault still models a Data Vault for teams that want one, seeding its hubs, links and satellites from your staging tables. AIMS is the default we now argue for.