The Medallion Pattern in Practice: Bronze, Silver, Gold for Public Sector Data
By Rplus Analytics · Data Engineering · Architecture
The medallion architecture — Bronze, Silver, Gold — has become close to a default for modern data platforms, and for good reason. It gives teams a shared vocabulary, separates concerns cleanly between ingestion and modelling, and creates natural boundaries for governance and quality controls. (PRJ8500)
But "we use medallion" hides a lot of variation. The same three-layer label gets applied to platforms that are genuinely well-organised and to platforms that are essentially raw dumps with two views over the top. This post is about what each layer should actually contain, where the design discipline matters most, and how the pattern interacts with governance — particularly in public sector contexts where audit and lineage requirements are non-negotiable.
What each layer is for
Bronze: raw, ingested, immutable.
Bronze is the landing zone. Data arrives here in roughly the shape it left the source system — schema preserved, no business logic applied, no joins performed. The cardinal rule: Bronze is append-only and immutable from the platform's perspective. You can rebuild Silver and Gold from Bronze. You cannot rebuild Bronze from anywhere else without re-ingesting from source, which may not be possible.
This is what makes Bronze the spine of your audit story. Every query a downstream user runs can, in principle, be traced back to a specific snapshot of Bronze data. Every regulatory question about "what did we know on date X" has a defensible answer.
Silver: filtered, cleaned, conformed.
Silver is where the platform earns its keep. Data is deduplicated. Joins across source systems are made explicit. Reference codes are decoded into human-readable values. Inconsistent date formats are reconciled. Slowly-changing dimensions are tracked properly. Personally identifiable information is masked, tokenised, or quarantined according to your data classification rules.
Silver is the layer your data scientists and analysts should work from, not Bronze. If they're routinely reaching into Bronze, your Silver layer isn't doing its job.
Gold: business-level, aggregated, ready to serve.
Gold tables are purpose-built for specific consumption patterns — a particular dashboard, a particular ML feature set, a particular cross-departmental data product. They tend to be denormalised, pre-aggregated, and tuned for query performance rather than storage efficiency.
The rule of thumb: Gold tables should be cheap and fast to query, even if they're expensive to build. The work done at Gold-build time saves work at every query that follows. (DSA)
The discipline that separates good from bad implementations
Three habits, in our experience, distinguish medallion implementations that age well from those that quietly rot.
One. Bronze stays raw. The temptation to "just clean this one obvious thing" at ingestion is real and persistent. Resist it. Every transformation in Bronze breaks the audit guarantee that Bronze is supposed to provide. If a field needs cleaning, that's Silver's job.
Two. Silver is the canonical model. Silver should embody your enterprise data model — the canonical representation of customer, citizen, claim, transaction, or whatever your core entities are. Multiple Gold tables can derive from the same Silver tables, but Silver itself should be the single source of truth for "what is a thing."
Three. Gold tables have owners. A Gold table without a clear business owner is a Gold table that will quietly drift out of usefulness. Each Gold table should be tied to a specific consumption use case and a specific person or team accountable for it.
Governance lives at the boundaries
The medallion structure also gives you natural places to put governance controls.
At Bronze ingestion — data classification, source-system lineage, retention policy attachment. This is where every record gets tagged with where it came from, when, and how sensitive it is. Get this right and the rest of the platform inherits it.
At Bronze-to-Silver — quality checks, masking and tokenisation of sensitive fields, validation against expected schemas. Records that fail quality gates either go to a quarantine table or block the load entirely, depending on your tolerance.
At Silver-to-Gold — access controls, row-level security, anonymisation aggregation thresholds. Different Gold tables can expose different views of the same Silver entity to different audiences, governed by row-level security rules tied to user identity and role.
At Gold serving — query auditing, usage tracking, sharing agreements. This is where the platform records who asked what, which is the data trail external auditors and information governance teams will eventually want.
A unified catalog (Unity Catalog, Snowflake Horizon, Informatica Data Governance, or similar) makes this work consistently across the whole platform rather than as ad-hoc rules per layer.
Cross-departmental sharing through Gold
For UK public sector platforms, Gold is also the natural sharing boundary. Bronze is too raw to expose — it carries source-system idiosyncrasies and may include unredacted sensitive fields. Silver embodies an internal data model that other departments shouldn't need to reason about.
Gold tables, by contrast, are shaped for specific business questions. They're the right granularity to expose to other departments through Delta Sharing, Snowflake Data Sharing, or equivalent mechanisms — under a Data Sharing Agreement that specifies exactly which Gold tables, with what frequency, to which downstream consumer.
This makes Gold the layer where information governance, technical access control, and inter-departmental policy all meet. Designing Gold tables with sharing in mind from the start, rather than retrofitting it later, is one of the higher-leverage decisions a public sector data architect makes.
A practical starting point
If you're standing up a medallion platform from scratch, three early decisions matter most:
- Pick your open table format and stick to it across all three layers. Don't write Bronze in one format and Gold in another. The whole point of a unified format is consistent tooling and lineage.
- Build Silver before you build Gold. The temptation to skip straight from Bronze to a useful dashboard is strong. Resist it. Every Gold table built directly on Bronze is a future migration.
- Wire up the catalog on day one. Lineage you collect from the start is dramatically more useful than lineage you reconstruct later. Most platforms underinvest here and pay for it within eighteen months.
---
Rplus Analytics designs and operates medallion-pattern data platforms for UK central government. If you'd like to discuss your platform design or governance approach, get in touch.