Bronze, Silver, Gold: What Each Layer of a Medallion Architecture Is Actually For

A practical breakdown of what Bronze, Silver and Gold are each responsible for in a medallion architecture, and why blurring those boundaries is what actually breaks data platforms.

“Medallion architecture” gets thrown around a lot in Fabric and Databricks conversations, usually alongside a tidy diagram with three coloured boxes and some arrows. The diagram is fine. What it tends to leave out is the part that actually matters: what each layer is responsible for, who or what should be allowed to touch it, and what goes wrong when those responsibilities blur together. We build this pattern into most of the data platforms we deliver, so this is the version with the detail left in.

Bronze: keep everything, judge nothing

Bronze is the layer people misunderstand fastest, usually by assuming it needs to be useful. It doesn’t. Bronze’s only job is to hold an unaltered copy of whatever arrived from the source system, in the shape it arrived in. If Business Central sent a duplicate invoice because of a retried API call, Bronze keeps the duplicate. If a CRM export had three different date formats because someone changed a regional setting last March, Bronze keeps all three. No validation, no deduplication, no reshaping. The moment you start “fixing” data on the way into Bronze, you have quietly deleted your own audit trail, and you won’t notice until you need it.

In a Fabric lakehouse this usually lands as Delta tables in OneLake, ingested through Data Factory pipelines or Fabric’s native connectors, partitioned by source and load date rather than by anything business-meaningful. Metadata about when a file landed and where it came from matters more here than the content of the file itself.

Silver: where validation and deduplication actually happen

Silver is where Bronze’s raw honesty gets turned into something a business can actually use, and it’s where most of the real engineering effort in a platform build goes. Deduplication happens here, because Bronze’s job was to keep every duplicate, not resolve them. Records get conformed to agreed keys and types, so a customer ID means the same thing whether it came from the CRM or the finance system. Quality rules get applied and, critically, get recorded when they fail rather than silently dropping the row. A negative stock figure, an order with no linked customer, a date field that didn’t parse: Silver is where you decide what “acceptable” looks like and start measuring against it consistently.

This is also usually where the grain gets fixed. Source systems rarely agree on what a “row” represents, and Silver is the layer that settles it, before anyone downstream has to guess.

Gold: built for a question, not for storage

Gold is business logic, not more cleaning. By the time data reaches Gold, it should already be trustworthy; what happens here is shaping it for a specific purpose. Aggregations, denormalisation, star schemas built around a particular reporting need, calculated measures that encode an actual business definition of “active customer” or “completed order” rather than a technical guess at one. This is the layer a certified semantic model sits on, and in a Fabric estate it’s usually what Power BI reads directly through Direct Lake mode, without a separate copy of the data being pulled anywhere.

The mistake we see most often here isn’t technical, it’s structural: teams building one enormous Gold layer meant to answer every question at once. Gold works best built around specific, known consumption patterns. A finance reporting Gold table and an operations dashboard Gold table can both come from the same Silver data and still look completely different, because they’re shaped for different questions.

Why the boundaries matter more than the tools

None of this depends on a specific product. You can build a clean Bronze, Silver and Gold separation on Fabric, on Databricks, or on a conventional warehouse if you’re disciplined about it. What actually breaks platforms is not choosing the wrong tool, it’s letting the layers blur: validation logic creeping into ingestion, Gold tables getting used as a substitute Silver layer because it was faster that week, business logic scattered across three different notebooks with no single owner. We cover where this fits alongside other architecture patterns in choosing the right data architecture, and how it plugs into a wider build in our Fabric Launchpad approach.

Get the layer boundaries right early and the rest of the platform tends to look after itself: reporting is faster to build, quality issues are easier to trace to a single stage, and nobody has to touch the raw layer just to fix a mistake made three steps downstream. If you want a second opinion on how your own Bronze, Silver and Gold layers are actually holding up, that’s a conversation we have often. Get in touch at hello@hoptonanalytics.com and we’ll take a proper look.