Bronze shipped a year ago, and gold still isn’t trusted. In a medallion architecture, the integration layer is the silver work between the two. Raw bronze is conformed there into the agreed business entities gold aggregates and serves. So the gap in your medallion architecture isn’t a missing platform feature. It’s six pieces of work nobody put on a calendar.

Where do you start an integration layer?

Pick one subject area: Customer, Order, or Product. Walk it from what the business means by the word to a generated, reviewed, committed integration layer.

One governed subject delivered in six weeks teaches you more than a six-month charter and leaves something running. The steps run in dependency order, with steps 1 and 2 in parallel and step 3 the first that needs both.

Six steps, each leaving a decision for the next

Step 1: Agree the language and set naming conventions

Write down the entities, their definitions in business terms, and the synonyms the business uses. Write each relationship as a sentence. Give every entity a business key, or a note that nobody can name one. Then set your naming conventions as ordered steps somebody can execute, not a style preference.

You’re done when a relationship reads aloud as a sentence the business would say and its expert agrees it’s true. The way this fails is the enterprise-wide business glossary program: a year of workshops, a taxonomy nobody consumes, and no subject area finished.

Step 2: Register and profile every source

Build a register with one entry per source and an honest note on what each can and can’t be asked. Add an inventory of tables and columns keyed on stable identifiers, imported as a diff somebody approves. Then profile the data. The schema is a claim, and the data is the witness. You’re finished when you can answer “what can this source not tell us” for every source.

The failure here is quieter than in step 1. You trust the schema as the truth about the business. But what does a foreign key tell you? It says two tables are related. It can’t say what the relationship means. Only step 1 can.

Step 3: Build the source-to-target mapping for one subject area

The source to target mapping binds the physical estate to the agreed language: source table to entity, source column to attribute. Every decision carries its decider, date, and reason. Let disagreement be an outcome too. A rejection with a recorded reason stops the same wrong suggestion coming back next quarter. Step 3 is done when a governed attribute traces to every column that populates it.

What kills it is a mapping spreadsheet with a deadline and no owner, stale by next sprint. The mapping is the deliverable makes that case, and The model says yes, the source says no makes it at column grain.

Step 4: Choose the shape, from Data Vault to one big table

Data Vault, third normal form, dimensional, one big table: weigh what separates them, starting with these four.

  • Change frequency. Ask how often your sources change shape and what each shape makes you redo.
  • Audit demands. Learn what your auditors ask for, and whether the shape answers without a reconstruction project.
  • On-call skills. Know what your team can run at three in the morning, unaided.
  • Query cost. Work out what each shape costs to query on your platform at real volumes.

Write the decision down with those factors, the date, the deciders, and the business-key rulings underneath it. Step 4 is finished when the rationale sits in the catalog, where the next engineer finds it, not in a slide deck. Shapes get chosen badly, by religion or the last conference somebody attended. And how raw your Data Vault is is the same ruling one layer down.

Step 5: Write the templates and their metadata contract

Define a pattern per object kind. Then declare your conventions as metadata, not code: naming rules, system columns and their roles, hashes, and type mappings. Add bindings saying which pattern serves which object, then prove a render against real metadata.

Name the template author too. In most teams there isn’t one, and the patterns become whatever the last contractor left behind. You’re done when you change one naming pattern and every generated name moves with it. The first hand-edit of generated output undoes the step quietly.

Step 6: Generate, validate, and keep a committed history

Build a reviewable artifact set, pass or fail on every file, not a script writing straight into a schema. Point your validation rules at that set, tuned so every finding is actionable. Then put the whole model on branches, with diffs a reviewer can read, a commit gated by the validation rules, and a history that survives a delete. Done means you can answer “who accepted this, and when” for any object. It all comes to nothing if the catalog can’t be diffed.

Why the second subject area is faster than the first

Does step 6 end the work? It doesn’t. It feeds step 1. The decisions you recorded on this pass are the context the next one reads. A naming rule settled once generates the next hundred names without anyone reopening the argument. Your decisions become the process. So the tenth subject area is routine, and the silver layer stops being the part nobody shows you.

Now count the platform decisions above. There aren’t any. Query cost in step 4 is a platform factor, not a decision. Every platform tells you to land your data and let its AI do the rest. But the rest assumes somebody did all six steps. No vendor sells you those. And none stop you building them.

These six steps run at full length in the long-form chapter that closes The Data Lakehouse for Everyone.

So pick your subject area this week and book the first meeting: a modeler, a steward, and the business expert who can settle what a customer is. That hour is step 1.