Technical note

The Medallion Pattern Explained for Business Reporting

8 min read · Published 18 June 2026

• Analytics Engineering
• Data Modeling
• Medallion Architecture
• Reporting Trust

The medallion pattern is often explained as bronze, silver, and gold.

Raw. Cleaned. Curated.

That is directionally useful, but it can become too neat.

For business reporting, the value is not the metal names.

The value is knowing what changed between the source record and the number used in a decision.

If the layers clarify that path, the pattern helps Reporting Trust.

If the layers only rename folders, they do not.

The symptom: nobody knows which layer to trust

At Brightside Bikes, a data team might have:

• Raw Shopify exports.
• Cleaned Shopify order models.
• Order-line facts.
• Weekly revenue marts.
• A leadership dashboard.

Someone asks why revenue changed.

The team then has to work out whether the change came from:

• A source system update.
• A loader issue.
• A cleaning rule.
• A refund treatment.
• A SKU mapping change.
• A finance adjustment.
• A dashboard filter.

The medallion pattern should make that investigation easier.

It should show where source data ends, where business logic begins, and where decision-ready reporting is published.

Bronze: preserve the source signal

Bronze is the source-aligned layer.

It should preserve what arrived from the operational system with minimal interpretation.

For Brightside Bikes, bronze might include:

• Raw Shopify orders.
• Raw Stripe charges.
• Raw ad spend files.
• Raw inventory snapshots.
• Raw HubSpot contacts.

The job of bronze is not to be pretty.

The job is to preserve evidence.

When a number changes unexpectedly, the team needs to know whether the source data changed or whether the transformation logic changed.

Bronze helps answer that.

Silver: standardise and make usable

Silver is where source records become more usable.

Common silver work includes:

• Renaming fields.
• Casting data types.
• Removing test records.
• Standardising timestamps.
• Flattening nested structures.
• Deduplicating source rows.
• Applying basic quality checks.
• Creating stable keys.

For example:

select
  cast(id as string) as order_id,
  cast(customer_id as string) as customer_id,
  created_at at time zone 'UTC' as order_created_at,
  total_price::numeric as gross_revenue_amount,
  total_discounts::numeric as discount_amount,
  coalesce(test, false) as is_test_order,
  coalesce(cancelled_at is not null, false) as is_cancelled
from bronze_shopify_orders;

This model is not yet the final revenue definition.

It is making the source consistent enough for business modeling.

Gold: publish decision-ready meaning

Gold is where approved business logic is published for consumption.

For Brightside Bikes, gold might include:

• mart_weekly_operating_report
• mart_weekly_revenue_bridge
• mart_customer_lifecycle
• mart_product_margin
• mart_inventory_risk

Gold models should be close to business language.

They should answer specific reporting questions and carry the approved definitions.

Example:

select
  reporting_week,
  sum(shopify_net_revenue) as shopify_net_revenue,
  sum(finance_revenue) as finance_revenue,
  sum(contribution_margin) as contribution_margin,
  sum(active_bike_owners) as active_bike_owners
from mart_weekly_operating_report
group by 1;

The dashboard should not have to rediscover these definitions.

It should consume them.

The layer names are less important than the layer contract

Teams can use bronze, silver, and gold.

They can also use raw, staging, intermediate, marts.

The names matter less than the contract.

Each layer should answer:

• What is allowed to change here?
• What logic belongs here?
• What tests protect this layer?
• Who uses this layer?
• What downstream reports depend on it?

If those questions are unclear, the medallion labels create an illusion of control.

What belongs in each layer

A useful business-reporting interpretation looks like this:

Some teams treat facts and dimensions as silver.

Others treat them as gold.

That is less important than whether the team can explain where raw source handling ends and business definition begins.

Medallion layers should reduce debugging time

When Brightside Bikes sees an unexpected revenue movement, the team should be able to debug by layer.

First, did the raw source change?

Then, did the staging logic change?

Then, did the business fact or dimension change?

Then, did the mart change?

Then, did the dashboard apply an additional filter?

That path is faster than searching across every query and report.

It also makes incident review more factual.

The team can say, “The source sent late refunds,” or, “The SKU cost map changed,” or, “The gold mart excluded cancelled orders after the latest release.”

That is Reporting Trust in practice.

The pattern can fail

The medallion pattern fails when teams treat it as storage organisation rather than business control.

Common failures include:

• Bronze data is overwritten, so source history is lost.
• Silver models contain hidden business definitions.
• Gold models are too raw for executives to use.
• Dashboards still perform key joins and calculations.
• There are no tests between layers.
• Nobody knows which layer is authoritative.

In those cases, the architecture looks mature but the reporting remains fragile.

What to inspect first

For a medallion-style project, inspect:

• Are raw source records preserved enough for reconciliation?
• Are staging models limited to source standardisation?
• Where do business definitions first appear?
• Are facts and dimensions documented by grain?
• Are gold marts named in business language?
• Do dashboards consume gold models or rebuild logic?
• Are tests mapped to each layer’s risk?
• Can the team trace a board metric back to bronze?

If the answer is no, the layers may be decorative rather than operational.

What good looks like

For Brightside Bikes, good medallion architecture means the weekly operating number has a traceable path.

Shopify sends source orders.

Bronze preserves what arrived.

Silver standardises the source.

Facts and dimensions define orders, products, customers, and timing.

Gold marts publish weekly revenue, margin, customer, and inventory views.

The dashboard consumes the mart.

When a number changes, the team can see which layer changed.

That is the point.

Not bronze, silver, and gold as labels.

But a controlled path from operational data to trusted business reporting.