Medallion architecture uses bronze, silver and gold layers to separate source capture, data preparation and business definitions. Use it when several reports depend on shared rules, or when a team needs to explain how a reported figure was produced. Choose one reporting decision and work backwards through the records and rules it needs.
An order report is useful until somebody asks why its backlog differs from the figure in another report. The totals may cover different statuses or different extracts. A staffing decision now waits for somebody to work through the calculations.
The three layers make that investigation easier to organize. Engineers can examine the captured records, check their preparation and then inspect the definition used by each report.
Start with the reporting decision
The report you need determines what the layers must preserve and explain. Dispatch may need yesterday's backlog alongside today's count, with individual orders available for inspection. That requirement already tells the engineer something important: retaining only totals will be insufficient.
The comparison needs history. The count needs an order identifier and a rule for selecting statuses. Deciding those requirements early prevents a later discovery that the extract discarded something necessary.
Databricks describes medallion architecture as progressively preparing raw data for business use. The pattern organizes the responsibilities. The intended report determines which records, checks and definitions belong within them.
Preserve what the source supplied
Bronze keeps the records and extraction context needed to investigate or repeat a calculation. When yesterday's report is questioned, an engineer needs to recover its input. Querying the source today may produce a different set of statuses.
Keep the source identifier and extraction time with the retained records. They help distinguish a later correction from a mistake in the earlier report. Both the earlier state and today's state may be needed, depending on the question.
Retention and access deserve explicit decisions. An extract may contain sensitive fields that never appear in the report. Limit who can read them and retain them for the period the work requires.
Resolve shared rules before reporting
Silver gives different reports a consistent treatment of the same records. It is where shared preparation resolves identifiers, types and relationships. Once those rules are applied, each report can concentrate on its own business measure.
Consider an order that appears twice in an extract. The order ID and version should establish whether the second row repeats the first. Then examine joins: adding several order lines to a single order can accidentally multiply a count.
Keep evidence of rejected records, including the failed validation rule. An operator needs to establish whether their absence changes the report enough to delay its release.
Corrections that arrive late require a further choice. Recalculating a prior day may be appropriate, but recipients need to see that its published number changed. Retain the earlier version where it is needed to explain the difference.
Give business measures a stable meaning
Gold expresses the definitions people use to make decisions. An open-order view should specify the statuses it includes and when the count applies. Its unit should also be explicit: an order, an order line and a shipment are different things to count.
Planning might include orders awaiting stock, while dispatch counts only those ready to ship. Both views can be valid. Their names and definitions should make the difference apparent to their readers.
Reports and AI questions can use those established views. With the executed query beside an answer, a reviewer can check the selected measure and inspect the calculation. The underlying source relationships have already been resolved for that use.
A gold label does not establish that a measure is correct. Test the view against known cases, including cancellations, missing relationships and period boundaries. Review the output with the people who use it before making it the basis of routine decisions.
Choose where to store the results
The three responsibilities do not require three separate platforms. They can be represented through tables, views and transformations within a chosen environment. Decide which results need to be stored and which can be calculated when requested.
Stored intermediate results can make repeated work faster and simplify investigation. They also create refresh dependencies and another result to maintain. Views reduce stored duplication, but their performance and availability depend on the queries beneath them.
The useful question is what each boundary accomplishes. It may preserve source evidence, isolate a shared rule or provide a stable interface for reports. A copied table that serves none of those purposes adds work without helping the reader of the report.
Keep source timing visible throughout the design. Refreshing a dashboard more often cannot reveal records that have not yet reached its source. Match the refresh schedule to the decision and to the updates actually available.
Keep the layers working together
A usable architecture includes the checks and support that keep reports dependable after release. Separate an arrival problem from a preparation problem and from an incorrect measure. That makes an incident easier to locate and explain.
When the source introduces a new status, follow its use through the affected views. Compare the figures before releasing a revised rule. Recipients also need an explanation if the change alters how they read their report.
Databasin combines the data foundation with definitions, reporting, rollout and ongoing support. The implementation includes getting the report into use and maintaining it afterwards. A connection that still runs is only one part of that responsibility.
Example: tracing an order backlog
This illustrative dispatch review explains how 125 incoming records become a backlog of 30 orders.
| Stage | Records and rule | Result for the review |
|---|---|---|
| Bronze, 07:00 | Retain 125 records and the extract timestamp. | The morning input is available for inspection. |
| Silver | Remove five repetitions of the same order ID and version. | The prepared data contains 120 distinct orders. |
| Gold | Include the 30 orders marked “Awaiting dispatch”; exclude the remaining 90. | Thirty orders meet the backlog definition. |
| Report, 08:00 | Apply the same definition to yesterday's equivalent extract: 24 orders. | Six more orders are waiting today. |
| Investigation | Examine location and waiting time for the included orders. | The manager decides where to investigate dispatch. |
The layers preserve the evidence behind the count. They let the manager question the increase without starting again from the source system.
Before the first release
- Choose one decisionEstablish what the recipient needs to decide, then identify the measures and retained records that would let them explain the answer.
- Define each boundarySpecify what the extract preserves, which preparation reports share and what each measure counts. Assign responsibility for maintaining those rules.
- Test the exceptionsExamine duplicates, late arrivals and missing relationships alongside ordinary records. Check how each case affects the total shown to the reader.
- Plan ongoing operationInclude refresh monitoring, corrections and support in the release. Show recipients how to interpret a measure and report a problem.
Sources
Databricks, What is the medallion lakehouse architecture?, 2026 · docs.databricks.com/gcp/en/lakehouse/medallion
Talk through the data behind decisions
We can discuss the reports your team relies on, where their numbers become difficult to explain and how the underlying data could work better. A demo can explore the definitions, delivery and support involved.