Every method stops at the concept
Every silver layer modeling method that carries meaning will tell you which business thing a table is about. Only the most expensive one tells you what its columns mean, and that’s the sentence an AI agent needs most.
The methods aren’t careless. Each one that carries meaning states it down to that business thing, the table’s concept, and then stops one step short.
Your platform won’t settle it for you. Databricks’ glossary entry on the medallion architecture says “the Silver Layer has more 3rd-Normal Form like data models. Data Vault-like, write-performant data models can be used in this layer.” Databricks names two methods and requires neither. Microsoft’s guidance for Fabric and Snowflake’s documentation don’t name any. So the shape is yours to choose.
Six patterns, judged on what they do to a source table
- A canonical third normal form model redesigns the source. Inmon’s warehouse gives every concept one definition and bends every source into that shape before anything ships.
- Data Vault 2.0 splits the source. Linstedt’s hubs carry business keys, links carry relationships and satellites carry context, at the cost of several tables per source table.
- Hook wraps the source. Andrew Foad’s method keeps each table whole and adds business key columns, each labeled with the system and context it belongs to.
- A staging convention renames the source. One light layer per source table renames, casts and lightly cleans it, and defers integration.
- A mirror copies the source. It’s typed, deduplicated, validated and historized, and nothing more, so every gold model re-solves identity.
- An entity-shaped silver replaces the source. One table per business entity is fed by every source, and each source needs a mapping, plus a rule for which source wins, before anything ships.
What does every silver layer modeling method leave empty?
A silver table has to answer four questions. Which source record is this row? Which business thing is it about? How does it relate to the others? What does each column mean? The patterns that keep the source’s shape answer the first. Here are the other three:
| Pattern | Business thing | Relationships | Column meaning |
|---|---|---|---|
| Canonical third normal form | Yes | Yes | Yes, by rewriting every source |
| Data Vault 2.0 | Yes | Yes | No |
| Hook | Yes | Yes | No |
| Staging convention | No | No | No |
| Mirror | No | No | No |
| Entity-shaped silver | Yes | No | No |
The last column is empty in every row but one. The canonical model pays for filling that column with a rewrite of every source.
Can you fill it without the rewrite? You can, if the meaning lives beside the tables instead of in their shape.
Hook got closest, and it deserves the credit. It never restructures a table, it labels every key with its system, and nothing exists in it without a glossary definition. But Hook leaves what each column means to the team. Keep the shape, write down each column’s meaning where a machine can read it, and you’ve got the heart of AIMS, short for AI-ready, Meaning-first Silver. We set it out in AIMS: Rethinking the Lakehouse Silver Layer.
Where the AI payoff dies
Say your order system’s Customer table has a Name column, and your sales system’s Account table has an AccountName column. Both hold the customer account’s name. No pattern short of the canonical model has a place to say so.
What’s missing is one definition that both columns point to. That definition is a business attribute, Customer Account Name. The tie from a column to it is an attribute mapping. Without it, the gap shows up wherever the name is used.
- Gold re-derives the name per model. Every report decides for itself which column holds it.
- Cross-source joins work and comparison doesn’t. Identity joins the two systems, but units, currencies and codes stay unaligned.
- Sensitivity is classified per column. Masking belongs to the attribute, so mapping once should mask everywhere.
- Business-level lineage has no edge to follow. “What breaks if Customer Account Name changes?” needs the column-to-attribute edge.
Ask an assistant how many customer accounts you lost last quarter. It answers because the status column is mapped to a business attribute. That attribute carries the list of what each status code means, its code list. Take the mapping away and the assistant is left guessing from column names which status codes mean a lost account.
A level, not a gate
So why not require every column mapped before anything ships? Because agreeing what every column means is where a canonical model’s effort lives, and you’d rebuild its cost one column at a time.
AIMS treats mapping as a level a table reaches, a measure of how much it tells its reader, not as a gate. Mapping is mandatory only for the columns a join, the reading of a code or a governance rule depends on. Those are the ones that identify a record, point to another record, hold a code or hold sensitive data. AIMS calls these four classes critical, and mapping them is the line every table has to clear. Everywhere else, AIMS measures mapping as coverage, one visible number per table, and low coverage warns rather than blocks.
Mapping is cheaper now, too, because an AI proposes every column’s match, with its evidence, for a person to review.
Measure the empty column in your own silver layer before you choose a method:
- Pick the business entity your reports argue about most.
- List every column, in every source, that describes it.
- Mark the critical ones.
- Count how many of those are mapped to one written definition.
Every critical column without a mapping is a place where an AI answer guesses. Map those first, and let coverage track the rest.
In DeltaVault, the Map & Match workbench suggests an attribute match for every column of a table, with a confidence score and a written rationale that an accepted match keeps.