Medallion architecture has become the default mental model for organizing a data platform: land raw data in Bronze, clean and conform it in Silver, serve trusted, business-ready data from Gold. It’s simple, it’s intuitive, and it works, right up until three teams build three different “customer” tables and nobody can agree on the number in the boardroom.

That failure mode isn’t a medallion architecture problem. It’s a missing canonical model problem. The two ideas are often treated as separate concerns (one about pipeline structure, the other about data modeling), but they need each other to actually deliver on the promise medallion architecture makes. Where exactly they meet isn’t fixed, though. It’s tempting to say “the canonical model lives in Silver,” but Silver is rarely one uniform thing, and plenty of organizations push canonicalization later, or keep it entirely outside the medallion layers. What matters is knowing where that intersection actually is in your own architecture, because that’s the point everything downstream depends on.

Two different questions

Medallion architecture answers: when should data get refined?

• Bronze: not yet, capture everything, as-is, even if it’s messy.
• Silver: partially, handle broken rows, line up common fields, apply basic joins and business logic.
• Gold: fully, curated, stable, ready to power dashboards and ML.

A canonical model answers a different question: what shape should the data be in once it’s refined? What does “Customer” mean across the business? What’s its key, its required attributes, its valid values? Which system is the source of truth when two upstream systems disagree?

Medallion architecture without a canonical model tells you where to put clean data. It doesn’t tell you what “clean” means. That gap is where things quietly go wrong.

The intersection is a boundary, but not always the same one

It’s tempting to say “the canonical model lives in Silver,” or even to tighten that to “canonicalization happens once, at the Bronze to Silver boundary.” Neither is reliably true. It depends on how a given organization actually builds Silver.

In practice, Silver is rarely one homogeneous thing. It often contains a mix of:

• lightly cleaned source tables, still shaped like their source
• standardized source tables (types, naming, encoding fixed, but still source-oriented)
• CDC history, preserved for lineage and replay
• conformed entities, mapped onto a shared definition
• enriched source-specific data that never gets conformed at all

Many organizations keep Silver deliberately source-oriented, because different downstream use cases need different things from it, and they push canonicalization later, or elsewhere. The canonical model doesn’t have to live inside Silver at all. It can sit in a dedicated semantic layer, a modeling layer that spans or sits above Silver and Gold, or even entirely outside the medallion structure as its own governed artifact that multiple Gold marts reference.

So the more accurate statement isn’t “canonicalization happens at one fixed point.” It’s this: wherever canonicalization happens in your architecture, that’s where medallion architecture and canonical modeling intersect, and in many real implementations, that point is not the Bronze-to-Silver boundary, and it may not be Silver at all.

Bronze is the one layer that’s reliably pre-canonical. It stays raw and source-shaped on purpose; that’s what makes it useful for replaying and auditing. Beyond that, where exactly the canonical model gets applied is an architectural choice, not a fixed rule.

Gold often consumes canonical entities, but it frequently defines something else: business semantics. Canonical entities (Customer, Order, Product) and business metrics (Net Revenue, Active Customer, Monthly Recurring Revenue, Customer Lifetime Value) aren’t the same kind of thing. A canonical entity is a shared structural definition: a stable key, a grain, an agreed set of attributes. A business metric is a derived meaning built on top of one or more entities, and it usually can’t be defined until analytical modeling is underway. What counts as “active,” what’s included in “net” revenue, how churn factors into CLV: these are decisions that emerge from building the Gold layer itself, not from the canonical model it consumes. So Gold isn’t purely downstream of meaning. It’s frequently where a whole category of business meaning gets settled for the first time.

The failure mode, named

Most medallion architecture write-ups include some version of this warning: don’t let every team build their own hidden mini-Gold tables.

That instruction only works if there’s something to conform to, and if it’s clear where that conformance is supposed to happen. Without a canonical model governing that point, wherever it is, each team ends up quietly inventing its own version of “customer,” “order,” or “active user.” Tables further downstream look clean; they passed their checks, but they’re clean according to nobody’s agreed definition. Gold then inherits several slightly different truths, and the trust the whole architecture promises (“curated, trusted data”) evaporates the first time two dashboards disagree.

This isn’t a hypothetical. It’s the most common reason data platforms that look architecturally sound in a diagram still produce “which number is right?” arguments in practice.

Making it concrete

If you’re implementing this, treat the canonical model as a first-class artifact, not an implicit side effect of however Silver happens to get built, and not assumed to live in any one fixed place:

• Own it. Someone (a data modeling lead, a domain team, a governance function) owns the definition of each canonical entity: its grain, its key, its required and optional attributes, its allowed values.
• Version it. Canonical definitions change as the business changes. Treat changes like schema migrations, not silent edits.
• Know where conformance actually happens in your architecture, and enforce it there. That might be at Bronze-to-Silver, later within Silver, in a dedicated semantic layer, or somewhere else entirely, but it has to be a known, deliberate point, not wherever each pipeline happens to land.
• Require traceability in Gold, and treat metric definitions with the same rigor as entity definitions. Every Gold mart should be able to point back to the canonical entities it derives from. But metrics like Net Revenue or Customer Lifetime Value are usually born in Gold, not inherited from it, so they need their own owner, their own written definition, and their own version history, the same way a canonical entity would.

the wrap

Medallion needs an explicit semantic agreement layer. In some organizations that’s a canonical model. In others it’s conformed dimensions, a semantic layer, domain data products, or governed metric definitions. The architectural pattern matters less than ensuring that business meaning is defined once and reused consistently.