Further Reading: The Medallion Architecture

Sources are tagged Tier 1 (confident it exists, recommended without reservation) or Tier 2 (real and worth seeking, but confirm the current edition, version, or URL yourself).

A warning about this literature specifically. The medallion architecture has more written about it than almost any pattern in this book and most of it describes the three boxes and stops. The boxes take a paragraph. What is worth reading is anything that states a guarantee or an enforcement mechanism, and that is a much shorter list — which is why several entries below are about the older ideas the pattern descends from rather than about the pattern itself.

The ancestors, which are better written than the descendant

Ralph Kimball, The Data Warehouse Toolkit (Wiley, 3rd ed. 2013), the chapters on the back room and on conformed dimensions. Silver is conformance, and Kimball wrote the definitive treatment of it thirty years before anyone said "silver." The staging-area material is §34.3, with more rigor and a longer track record. Tier 1.
Bill Inmon on the operational data store and the atomic warehouse layer. The other half of the argument, and the source of the "keep the raw detail" instinct that bronze formalizes. Read Inmon and Kimball as two answers to the same question, which is what they are, rather than as a feud. Tier 2 — a large body of work; one summary treatment suffices.
Dan Linstedt on Data Vault, particularly the raw-vault / business-vault split. This is the same boundary as silver / gold, stated more precisely than the medallion literature ever does — the business vault is explicitly where interpretation lives, and the raw vault is explicitly where it does not. Worth reading even if you will never build a Data Vault, for the vocabulary alone. Tier 2 — the methodology has a lot of surface area; you want the layer-boundary chapters.

On the pattern as named

The Databricks documentation on the medallion architecture. Where the bronze/silver/gold naming became standard. Read it for the definitions and be aware of the framing — it is written by a vendor whose product makes the pattern cheap, and it does not spend much time on §34.14's "when not to." Tier 1 — versioned.
The dbt documentation on staging, intermediate, and marts. dbt's naming maps to silver/gold with an extra layer, and its "how we structure our dbt projects" guide is the most concrete enforcement advice available — naming conventions, ref rules, and directory-level configuration that makes some violations impossible rather than merely discouraged. Tier 1.
The dbt --select and --exclude graph selectors documentation. Not obviously about this chapter, and it is: dbt ls --select silver+ is a depth query, and the graph operators are how you compute blast radius in a real project without writing layer_check.py. Tier 1.

On enforcement, which is the whole chapter

dbt-project-evaluator — dbt Labs' own package of project-structure checks. It implements several of §34.5's rules already, including direct source references from marts (layer-skip) and models with no documentation. Run it before writing your own checker. Tier 1.
Anything on architectural fitness functions. The idea — an automated test that a system still has a structural property — is from Building Evolutionary Architectures (Ford, Parsons, Kua) and it is exactly what layer_check.py is. The generalization is useful: layer rules are one fitness function among many you could write. Tier 1.
Your linter's custom-rule documentation, whatever it is. SQLFluff for SQL, a dbt package, or forty lines of Python over manifest.json. The mechanism matters less than that it blocks a merge, which is §34.13's whole argument.

On what bronze is for

Chapter 31 §31.5 of this book. The Iceberg migration that made row-level deletes possible was funded by a privacy requirement, and it is the same decision as "bronze must be a table format" — which is where this chapter's replay guarantee and Chapter 31's deletion obligation meet.
The Apache Iceberg and Delta Lake documentation on time travel and schema evolution. Bronze's append-only requirement is much easier to honor with a table format than with raw files, and the schema-evolution material is what makes "keep unknown columns" practical. Tier 1 — versioned.
Anything on event sourcing's "the log is the source of truth." Chapter 36 takes this seriously. The relationship to bronze is direct — both are arguments that the raw, unmodified record should be retained and everything else derived — and the event-sourcing literature is more rigorous about the implications. Tier 2.

On the boundary cases

Martin Fowler on "the two hard things" and, more usefully, anything careful on ubiquitous language from the domain-driven design literature. §34.3's boundary problem is a naming problem: the moment a transformation needs a word from the business domain, it has left silver. Tier 1 for Eric Evans's Domain-Driven Design, the ubiquitous-language chapter.
The IANA time zone database documentation, and any careful treatment of timestamp handling. Case Study 2 is one instance of a very large class. The rule that generalizes — a timestamp without an offset is not a timestamp — is stated better in the tz-database material than anywhere in the data literature. Tier 1.

Practice

code/layer_check.py in this chapter. Nine rules, a replay planner with costs, depth and blast radius, and a drift check. Thirty-nine self-checks. Exercise 34.4 — expressing your own project in its graph format — is the most useful hour, and the violation count is usually a surprise.
Attempt a full rebuild. Exercise 34.12. If it succeeds on the first try, check that you rebuilt from raw rather than from something already materialized. Kestrel's failed three times in two years.
Compute depth and blast radius for your own project, and compare against where your assertions are. Exercise 34.8.
Scan for ambiguous timestamps. Exercise 34.13. Kestrel found 14 of 41 external timestamp columns arriving with no offset, and only 5 had been noticed.

A note on what to be skeptical of

Any description of the pattern that does not state a guarantee. "Bronze is raw data, silver is cleaned data, gold is business data" is three definitions and zero commitments. Ask what is true of a table in each layer, and if the answer is a description of its contents rather than a property you could test, the writing is decorative.

Any claim that the layers improve data quality. They provide a place to put a check. The check improves quality, and you can have the check without the layers.

Layer counts presented as universal. Three is a convention. Two is right for a single-source pipeline and five is right at scale, and a layer added because a different team owns it is not a layer at all.

And any adoption that does not come with an enforcement mechanism. After this chapter, "we use the medallion architecture" should prompt exactly one question: "what fails when someone violates it?"