The medallion architecture organizes a lakehouse into three layers of increasing quality: bronze for raw data as it arrived, silver for cleaned and conformed data, and gold for business-ready tables that reports read. Each layer is built from the one before, so problems can be traced back and data can be rebuilt.
For example, a retailer's orders flow through the layers like this. In bronze, bronze.orders_raw holds every line of every nightly file as it arrived, with the file name and load time. In silver, silver.orders holds one row per order line, with typed columns, consistent names, duplicates removed and rows that failed checks set aside. In gold, gold.monthly_sales holds revenue and order counts by month and region for dashboards. A wrong number in gold can be traced to silver, and from there to the raw line in bronze.
The layers separate concerns. Bronze is about not losing data, silver about getting each record right, and gold about answering business questions. Keeping them apart means a new business definition only changes gold, a fix to a cleaning rule rebuilds silver and gold from bronze, and a source change is absorbed at the edge. Access usually narrows toward bronze and widens toward gold.
The pattern is common on lakehouse platforms such as Databricks and Microsoft Fabric, but the idea is older than the name: staging, integration and presentation layers in data warehouses followed the same logic. What matters is that each layer has a clear purpose and that data flows forward through them. See also ELT and lineage.
Each layer usually lives in its own schema or catalog, such as bronze, silver and gold, which makes permissions and retention easy to set per layer. See also bronze layer, silver layer and gold layer.
Several of Emolysis's pipeline shapes map to these steps: Ingest (batch) lands bronze, Dedupe / conform builds silver, and Aggregation / gold builds gold. The layer names are a convention, not a rule: some teams add a fourth layer or use different names.