Data Engineering

The Medallion Masterclass: Why Knowing the Colors Isn't Enough

A practical guide to naming, ownership, access, governance, and when a Platinum layer actually makes sense.

If you work in data, you already know the definitions by heart.

  • Bronze is raw.

  • Silver is cleansed.

  • Gold is aggregate, business-ready data.

And you have seen this diagram about 1 million times:

You can recite it in an interview. You can draw the clean little three-stage diagram on a whiteboard. But when it is time to actually build it? That is when the diagram falls apart.

Suddenly, the real questions show up. Where do we actually filter out the nulls? Why does our Gold layer just look like a copy of our Silver layer? How do we handle schema naming? And why does every environment eventually end up with a table named gold.finance.month_end_final_v15?

At Gambill Data, we audit and architect enterprise platforms. We consult with everyone from PhD career-switchers to Directors of Data at global enterprises. And almost without exception, they all suffer from the exact same misconception: They treat Medallion Architecture as a storage pattern, when in reality, it is a strict governance architecture.

If you have been following me for more than a minute, you have probably seen my other piece about Medallion, telling you that it isn’t new. And it’s not. The whole concept of having raw, messy data land somewhere. Then polish it a little bit, followed by some enrichment, aggregation, and business rules. It’s been around since before Y2K. (And if you don’t know what that is, it’s been around before you were born.)

But, most teams learn the colors before they learn the operating model. They think Medallion is just a Databricks marketing term (Sorry Shane!). It isn’t. Whether your lead platform is Databricks (the enterprise standard for this model) or you are orchestrating a Microsoft Fabric environment, Medallion is the universal methodology for how you apply governance to a Lakehouse.

If you do not design your naming, ownership, access, and governance with intention, Medallion Architecture just becomes a color-coded junk drawer.

Here is the exact blueprint for the Why, How, and Where of Medallion Architecture.


The Paradigm Shift: It is an Operating Model

Medallion Architecture is not just a way to separate files and tables in your data lakehouse. It is a way to define how data enters your platform, how it gets standardized, how it earns trust, who gets to use it at each stage, and provides a maintainable framework to do it in.

“We don’t just build pipelines; we build data assets that the business can trust.”

- Gambill Data

To do that, you must use the platform’s physical structure to enforce human behavior.

The “How”: The Catalog Strategy

The architecture must be enforced by your namespaces, not by a wiki page. In a modern platform like Databricks Unity Catalog, you have a three-tier namespace (catalog.schema.table).

The standard requires Catalogs to represent Layer + Environment.

  • bronze_prod

  • silver_prod

  • gold_prod

  • platinum_prod

Why? Because Catalogs are your highest-level security boundary. If you grant an analyst read-access to gold_prod, they are safe. If you mix layers inside a single catalog, your permissions will eventually drift, and someone will accidentally drop a production table or expose PII.

The “Where”: Schemas Pivot from Source to Business

Once the catalog dictates the layer, the schema dictates the organization. This is where the structural pivot happens.

  • In Bronze, schemas align to the source system: bronze_prod.salesforce. (Because Bronze reflects the reality of where the data came from).

  • In Silver, Gold, and Platinum, schemas align to the business domain: silver_prod.finance or gold_prod.executive.

The Rule of Thumb: If the data still thinks like the software platform or vendor it was derived from, it belongs in Bronze. If it thinks like the business, it belongs in Silver, Gold, or Platinum.

Gambill Hint: In silver and above, your data should be platform agnostic. If your data migrates to a new platform silver + should be seamless to your business users and analysts.


So, What Actually Belongs in Each Layer?

Knowing “cleansed vs. raw” isn’t enough to write code. You need strict engineering boundaries. Ambiguity here kills data quality.

Bronze: The Immutable Ledger

Bronze is the receiving dock. Data shows up from source systems. It gets logged, landed, and tracked. Nobody pretends it is business-ready.

  • The “Why”: We need a perfect, immutable history of exactly what the source system sent us so we can replay pipelines if something breaks downstream.

  • The “How”: You ingest the data exactly as it arrived. You append metadata like _ingest_timestamp.

  • The “Where to draw the line”: Do not filter, clean, or cast data types in Bronze. If you alter the data before it lands and your logic is wrong, you have permanently lost the original data.

Silver: The Governance Boundary

Silver is the sorting floor. This is where data gets cleaned up, standardized, matched, and shaped into reusable building blocks.

  • The “Why”: Silver is where you ensure that a “Customer” means the exact same thing whether they originated in Stripe, Salesforce, or HubSpot.

  • The “How”: This is where you deduplicate records, cast strings to proper timestamps, handle nulls, and enforce data quality checks.

  • The “Where to draw the line”: Silver is for standardization, not business logic. If you are writing a massive GROUP BY statement to calculate Monthly Recurring Revenue, you have gone too far. That is Gold work.

Gold: The Business Product

Gold is the storefront. This is where trusted, business-facing data products live. This is what analysts, BI teams, and executives consume.

  • The “Why”: This is the ROI layer. The business doesn’t care about pipelines; they care about answers. Gold exists to answer specific business questions quickly and accurately.

  • The “How”: This is where your aggregations, KPI rollups, and strict dimensional models (Star Schemas) live. You optimize these tables for high-concurrency read performance.

  • The “Where to draw the line”: Gold is the data you are willing to stand behind in a boardroom. If a business user cannot safely query a Gold table without you sending them a three-page Slack thread explaining the caveats, remove it immediately. It is a liability.

If you learned it in this book… Gold is where it belongs, not silver, not bronze.

Measure What Matters - John Doerr

Platinum: The Machine Contract

Gold is built for humans to read. Platinum is built for systems to consume. Not every architecture requires a Platinum layer, but when you step into operational AI and application integrations, it is non-negotiable.

  • The “Why”: The question is no longer “Can a BI tool load this?” The question is, “Can our LLM query this without hallucinating?” or “Can our reverse ETL tool sync this to Salesforce without throwing a 500 error?”

  • The “How”: This is where you architect AI-ready chunked content, pre-computed vector embeddings, Feature Stores for ML models, and low-latency API feeds. Access is governed entirely by service accounts, not human user groups.

  • The “Where to draw the line”: Platinum is not a VIP lounge for important executives. It is a strict system contract. If a human analyst is querying the table for a Tableau dashboard, it belongs in Gold.


Governance is the Architecture

Governance is not some separate thing that lives in a slide deck or a policy document nobody reads.

Governance is part of the architecture. It shows up in naming standards, ownership metadata, automated lineage, and role-based access controls. If those things are not baked into how the platform physically operates, then governance is not embedded. It is just a PowerPoint presentation.

A clean Medallion model gives you clear boundaries for behavior, permissions, stewardship, and exposure. That makes governance easier to enforce because the structure actually supports it.

Stop Guessing. Build for Trust.

The real value of Medallion Architecture is not the colors. It is the clarity.

Clarity in naming. Clarity in ownership. Clarity in access. Clarity in what data is for, who it is for, and how much trust it has earned. If your current Lakehouse setup does not make ownership, access, and governance clearer, then it is not an asset. It is just that colored junk drawer.

If your organization is ready to stop wrestling with vague theory and wants to implement a pragmatic, battle-tested data architecture, Gambill Data is uniquely positioned to deliver it.

Stop guessing. Book a strategy call today.


Stop Doing Tutorials. Start Building Evidence.

If you walk into an interview with a sanitized, copy-pasted tutorial dataset, the interview is over. You don’t need another certificate. You need an undeniable portfolio of production-grade architecture.

The Gambill Portfolio Project Generator forces you to build “Code to Cash” systems that survive the War Room.

  • The Blueprint Engine ($59/mo): Paste the URLs of your target roles. Our AI engine cross-references your resume and generates a custom, enterprise-grade Statement of Work. Every technical task is mapped directly to a business outcome, exportable as an “Evidence Brief” to slide across the table at your next interview.

  • The War Room ($99/mo): Everything in the Blueprint Engine, plus gated access to the Director. Submit your milestones and get up to two asynchronous code reviews per month. I will tear down your architecture and expose your financial blind spots before a hiring manager does.

Don’t tell them you know data engineering. Prove it.