Medallion Architecture: Are We Applying Business Logic Too Early?

I’ve been spending a lot of time thinking about Medallion Architecture recently. Partly because it features heavily in some of the data projects I’m currently working on, particularly around Microsoft Fabric, but also because of a discussion at a conference I attended recently.

It challenged something that, on the surface, feels fairly straightforward:

Where should business logic actually live?

The more I’ve thought about that question, the less straightforward the answer has become.

The Medallion model makes sense

The basic principle behind Medallion Architecture is easy enough to understand. Data progressively moves through three layers:

• Bronze preserves the raw data.
• Silver cleans, validates, standardises and conforms it.
• Gold provides curated, consumption-ready data for analytics and reporting.

Microsoft describes the pattern in similar terms. In its Fabric guidance, Bronze stores data as it arrives, Silver fixes errors, standardises formats and removes duplicates, and Gold organises the resulting data for reports and dashboards.

There are variations, of course, but conceptually it's a useful model, the difficulty starts when we introduce business logic.

Cleaning data isn't the same as interpreting it

There is an important distinction between making data reliable and deciding what that data means to the business. If a date arrives in three different formats, standardising those formats is a data quality problem. If duplicate records exist, identifying and resolving them is a data quality problem. If an identifier must conform to an agreed structure, validating it is a data quality problem. Those are all reasonable things to deal with as data moves towards a clean and reusable Silver layer.

But consider something like:

What counts as an active customer?

Perhaps today the business defines an active customer as somebody who has purchased within the last 12 months, that's not really a data quality rule, it's a business definition. And we all now that business definitions have an inconvenient habit of changing.

Business logic changes

Imagine the business decides that an active customer should now mean somebody who has purchased within the last six months, the underlying transactions haven't changed, the customers haven't changed, and the dates haven't changed.

Our interpretation of those facts has changed.

If we've embedded that definition deep within our transformation pipeline, we now need to change the pipeline and potentially recreate datasets that depend upon it. More importantly, we may have lost something analytically useful.

What if somebody asks:

How many active customers do we have using today's definition compared with the definition we used last year?

That's a perfectly reasonable analytical question. But answering it becomes much harder if the earlier definition has already been baked into the data.

Preserve the facts

This is the part of the discussion I've found most interesting, a good analytical architecture shouldn't just produce today's answer, it should preserve enough of the underlying facts to allow us to ask tomorrow's questions.

That leads me towards a principle I've been thinking about:

Apply interpretation as late as practical, and preserve the facts for as long as possible.

That doesn't mean Silver should contain untouched raw data. That's what Bronze is for, Silver still has an important job to do.

Data can be validated, standardised, deduplicated, joined and conformed. We can create reliable representations of customers, transactions, products, locations and whatever other entities matter to the organisation.

But there is a difference between saying: "This transaction happened on 14 September for £1,000." and saying: "This transaction makes the customer active."

The first describes what happened, the second interprets what happened according to a business rule and that distinction matters.

So is Gold the answer?

This is where things become less clear, Gold is often described as the business-ready or consumption-ready layer.

Microsoft's Fabric architecture guidance, for example, describes the Silver-to-Gold transformation as creating business entities, dimensions, facts and aggregates, with Gold providing consumption-ready star schemas, data marts and preaggregated tables.

So putting business logic into Gold seems entirely reasonable, and in many cases, it probably is. But "ready for analysis" and "already interpreted" aren't necessarily the same thing. If we create a Gold table containing monthly revenue by customer, we've prepared the data for a particular type of analysis.

If we permanently classify every customer as Active or Inactive according to today's definition, we've gone a step further, we've embedded an analytical interpretation.

That might still be appropriate, particularly where an organisation needs a governed and consistent definition used everywhere.

But it should be a conscious architectural decision rather than simply: "Business rules go in Gold."

Then there's the semantic layer

This becomes even more interesting when Power BI and semantic models enter the architecture. Microsoft describes a Power BI semantic model as a logical description of an analytical domain containing metrics, business-friendly terminology and the structures needed to enable deeper analysis. Microsoft also describes highly curated semantic models as a place where complex business logic and sophisticated calculations can be abstracted and reused.

That gives us another potential boundary, instead of asking only: Bronze, Silver or Gold?

Perhaps we should also be asking: Should this rule exist in the data platform at all, or does it belong in the semantic layer?

• A calculation such as revenue might need to be consistently governed across an organisation.
• A definition such as customer status might need to change over time.
• A regulatory calculation may need to be versioned.
• An analytical hypothesis may only exist for a particular piece of analysis.

Those aren't necessarily the same architectural problem, and I'm increasingly unconvinced that they should automatically have the same architectural answer.

Business logic isn't one thing

Perhaps that's the bigger problem, we talk about "business logic" as though it's a single category, but it isn't.

• Some rules describe how data should be validated.
• Some describe how operational processes work.
• Some create standard business metrics.
• Some classify things according to current business policy.
• Some exist purely to answer a particular analytical question.
• And some need to change while the underlying historical data remains exactly as it was.

Trying to decide where "business logic" belongs without first understanding what kind of rule we're talking about is probably where the problem starts.

Architecture should preserve options

I'm not suggesting that business logic should never exist in Silver, or that everything should be pushed into Power BI, that would just replace one rigid rule with another. There are good reasons to materialise transformations earlier: performance, reuse, governance, consistency and avoiding every downstream system recreating the same logic.

But there is a trade-off, the further upstream we embed a changing business interpretation, the more downstream consumers inherit that interpretation, and the harder it can become to analyse the data differently later.

That's why I think the more useful architectural question isn't:

Which Medallion layer should contain business logic?

It's:

What do we lose by applying this particular rule here?

If the answer is that we lose the ability to reinterpret the underlying facts, compare different definitions or understand how a rule has changed over time, then perhaps that logic is being applied too early.

Final thought

I went into this thinking largely about Medallion Architecture, I've come away thinking much more about the distinction between facts and interpretation.

• Bronze gives us the source.
• Silver can give us reliable, conformed facts.
• Gold can make those facts easier to consume and analyse.
• The semantic layer can give those facts business meaning.

But the boundaries aren't absolute, and I don't think they should be. The important thing is understanding which transformations are correcting the data and which are interpreting it.

Business rules change what the data means.

And when that meaning can change, preserving our ability to reinterpret the facts might be more valuable than producing today's answer as early in the architecture as possible.

---

References

1. Microsoft Learn — Implement Medallion Lakehouse Architecture in Fabric
   Microsoft describes Bronze as raw, Silver as enriched through activities including error correction, standardisation and deduplication, and Gold as curated and organised for reports and dashboards.

2. Microsoft Azure Architecture Center — Modern Data Warehouse Medallion Architecture in Microsoft Fabric
   Microsoft's reference architecture describes the Silver-to-Gold stage as transforming Silver data into business entities, dimensions, facts and aggregates, with Gold containing consumption-ready star schemas, data marts and preaggregated tables.

3. Microsoft Learn — Power BI Semantic Models in Microsoft Fabric
   Microsoft describes a semantic model as a logical representation of an analytical domain containing metrics and business-friendly terminology.

4. Microsoft Learn — Semantic Models in Power BI
   Microsoft's guidance describes highly curated semantic models as providing reusable business metrics and abstracting complex business logic for calculations and analysis.

5. Azure Databricks — What is the Medallion Lakehouse Architecture?
   Databricks' guidance describes Silver as the layer for data cleanup and validation, while Gold is designed for business users and typically contains aggregated, business-focused datasets.