In this chapter
- Complete without integration. No shared key until a business requirement asks for one record.
- Matching and the golden record. Approved match rules, a shared key and a survivorship rule per attribute.
- Requirements, not preferences. What each business need calls for, and why audit needs nothing new.
When does a silver layer need integration structures at all? AIMS (AI-ready, Meaning-first Silver) answers “when a question needs one”, not “before anyone may read it”. And it builds them beside the tables, never instead of them.
A finished silver layer needs no integration structures
In the worked example, four source-aligned tables, one per source table, hold the order system’s customers, orders and order lines and the sales system’s accounts. Every row carries its readable business keys. Every reference has a role. The critical columns, the ones that identify, relate, hold a code or hold sensitive data, are mapped. Gold can read every table that passes the publish gate. Nothing in them is waiting for integration.
Silver layer integration is the last step you take when a question needs it, not the entry fee you pay before anyone may read the data. It’s level 4, Integrated, on the five meaning levels that say how much a table tells its reader. Placing it there revises our earlier silver posts. They asked for one governed Customer fed by every system that knows one.
Matching says two keys are one customer account
The finance team needs one customer list across both systems. But Customer Account has two business keys, one per record source, and they never join until an approved match says they describe the same thing.
A match states that two or more business keys denote one real-world instance of an entity. A person approves the match rules and types a manual match for an instance no rule can decide. The key register already lists every distinct business key of one entity across its record sources. Each run gives every row on it a shared key and what matched it. A manual match wins over every rule while its effective dates hold. A key nothing matched keeps itself as its shared key.
In the worked example, the rule is an exact match on a tax number. It finds that customer 00001042 under company code AU in the order system and account A-937 in the sales system are one customer account. Both rows get the shared key customer_account||tax_number||48123456789, and each says the tax number rule matched it.
A match is valid only between keys of the same entity. An organization and a billing account are connected by a relationship. A match between them would claim two things are one.
We left probabilistic entity resolution out on purpose. A match comes from an exact-match rule on a shared natural key or from a manual match a person types. The AI may suggest a rule, never a match, and no rule counts until a person approves it. Why draw the line there? A guessed identity is wrong in every join downstream of it. And nobody downstream can see which joins it touched. So AIMS would rather leave two keys apart than merge them on a likelihood, and it leaves a master data management engine out of scope.
The golden record sits beside what it summarizes
Then Customer Account gets a golden record beside its key register, one combined record per shared key. It holds the record sources that contributed to each, and a survivorship rule for every attribute it carries. A survivorship rule says which source’s value wins, by precedence of record source, by the most recent change, or by the first value that isn’t null in a stated order.
- Name survives from the sales system, with precedence wb, then awlt.
- Status survives from the order system, the only source that has it.
- Country survives from the sales system.
Survivorship works per business attribute. The rule can rank wb above awlt for Name only because both systems’ name columns are mapped to the same attribute, Customer Account Name. Without that mapping, they’re just two unrelated columns that happen to look alike. Our post “The Lakehouse Ended One Satellite Per Source” made the same point about the vault: “Conform the business attribute first, or you never get a common satellite at all.”
What makes this integration by exception rather than integration by rebuild? Sales Order keeps pointing at awlt||AU||00001042. Gold joins through the key register when it needs the shared key, and through the business key when it doesn’t. The golden record sits beside the four source-aligned tables. Nothing about them changed.
Figure 8.1: integration by exception. The four source-aligned tables unchanged, the key register carrying its shared key, and the golden record beside it.Which business requirement calls for more?
Customer Account met one business requirement. AIMS names the others, and what each calls for. So the build for each business area follows a requirement you can point to, not a preference nobody wrote down. Our first book left the choice of shape to you. Now that choice can follow the requirement.
| Business requirement | Build |
|---|---|
| One record source per entity, consumers doing analytics | Source-aligned tables only, levels 1 to 3 |
| Two or more record sources per entity and a consumer who needs one record, or an entity many gold products reference | A shared key on the key register, then a golden record, level 4 |
| Every source version kept for audit | Nothing new: bronze already keeps every version, before silver starts |
| Consumers that need a stable interface independent of any source | A golden record, a view or table beside the key register |
| Consumption | The mart, always |
Why does audit need nothing new? An auditor asks what each source sent and when. Persistent staging, the layer below silver that keeps every version a source delivered, already answers that. It sits in bronze, insert-only and in the source’s shape. A source-aligned table with a versioned or append history policy, the history chosen for it on purpose, shows the same history in silver, cleansed.
What about the things a vault was built for besides audit? Many volatile sources and parallel loading need nothing new either, because persistent staging loads one table per source table, silver keeps one table per source table, and each new source adds its own. A team organized around Data Vault is a preference, not a requirement. The mart closes that table, because consumption always needs one.
The mart reads the meaning layer
The mart reads the meaning layer, the business model plus the mappings that tie silver columns to it. The key register gives a dimension its natural key. Roles become role-playing dimension references, and the shared key, where matching exists, becomes a conformed dimension’s key map.
| The structural answer | A vault holds equivalence in a same-as link and the conformed view in a business hub and satellite, each with its own load, and survivorship sits in that load logic. |
| What the agent reads | The register’s shared keys with what matched each, every rule, which tables are summaries and which are sources, and the matching coverage, the share of keys something matched. |
| Yours to decide | Every match rule, manual match and survivorship rule, and when a business need calls for a golden record. |