Landing data in your bronze layer is a solved problem. Point any of this year’s AI tools at a source system and it will script the extraction, infer the schema, and have every table sitting in your lakehouse by lunch.

Bronze went first because bronze is the easy part of a medallion architecture. It asks nothing of you. There is no modeling to do, because the source system already did the modeling. There is no metadata beyond what the source publishes. There is no meeting where two departments have to agree on anything. So source-to-bronze is what every team building its own AI tooling ships first: the work is pure technology, and pure technology is exactly what AI accelerates best.

Replication in a medallion costume

There’s a pattern I keep noticing once the demo ends, and I have built it this way myself. Gold gets constructed straight off bronze: a view per report, a join per dashboard, every one of them reaching back into source-shaped tables. Silver, where it exists at all, is a rename pass. Same structures, friendlier names, with a patchwork of views stitched over the top to gloss over the agreement nobody ever made.

It is worth naming what that leaves you with, which is a replication service. You have copied your operational systems into a lakehouse with better file formats and a fresh coat of medallion vocabulary, and copying isn’t integrating. The cost lands the first time someone asks a question that spans business units: how many customers do we have, and which of them buy from both product lines. The platform has no answer, because the answer never lived in any single system you copied. I’d be interested in how others read their own silver layer on this. Is there anything in yours that no single source could have handed you?

Silver is a meeting, not a pipeline

The part of silver that resists automation is the part where two people have to agree. Silver is where data integration is supposed to happen, where data from different systems becomes one thing: one Customer, one Order, one structure the whole business recognizes. That has never been a technology problem. It is a people and process problem. Someone has to decide that billing’s account and support’s login are the same Customer, and then agree which system wins when the two disagree. Someone has to write that definition down and defend it the week finance and operations count differently. It is tempting to hope a smart enough inference step gets us out of that conversation, but so far nothing does.

The disciplines that solved this are older than the lakehouse. Inmon made “integrated” part of the definition of a data warehouse, and Kimball built an entire method on conformed dimensions. Those disciplines did not stop being right; they stopped being convenient. The inconvenience is exactly where the tooling drifts. Most of us building AI data tooling, myself included, come at the problem from the source side, where everything can be inferred, so the tools inherit the shortcut. Integration gets quietly replaced by whatever the sources already agreed on, which is nothing.

How do you know your silver layer is integrated?

Every metric that makes it into a data warehouse automation demo sits on the source side: how many systems connect, how fast bronze lands, how many pipelines got generated. I’ve reached for those numbers myself when showing work, because they are easy to count and they look like progress. Not one of them tells you whether anything was integrated. The measure I’d rather look at is the one nobody puts on a slide, which is how integrated the silver layer actually is. If silver holds one governed Customer fed by every system that knows one, the toolset is doing warehouse work. If silver holds a faithful copy of each source, then everything downstream is replication with extra steps, and the questions that span your business are still unanswerable.

That test is checkable at all because real integration leaves a record, and the record is a mapping. That thinking is the seam we’ve ended up building DeltaVault around: a business model that holds the agreed entities and their definitions, and Map & Match to connect sources to it, proposing which business entity each table represents and which attribute each column maps to. Every suggestion carries a confidence score and a written rationale, and nothing changes until a person accepts it. The proof is then one click deep, because you can open Customer and see every source table and column mapped to it, from every system that holds one. Other approaches will keep that record differently, and the record matters more than the tool.

The thing I’d let go of is bronze speed as a grading criterion. That race is over and everyone won it, which makes it a weak signal about anything. The more interesting conversation starts when you ask your own team to walk you through silver: one agreed model with every source mapped into it means you have a warehouse, and a list of views means you have replication and no answer to the cross-business questions.

Where I’m genuinely unsure is what counts as adequate evidence. If your silver layer earns the name, what would you point at to prove it: mappings, conformed keys, a written definition someone has defended in a meeting, or something I’m not thinking of?

The Data Lakehouse for Everyone opens on that question. Chapter 1 puts the deciding work on the arrows of the medallion architecture rather than inside its three boxes: The promise and the gap. Chapter 2 answers why bronze always ships and silver always stalls, and the reason is not technical difficulty: Why the silver layer fails.