Further Reading: Schema Evolution and Data Contracts

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).

Data contracts are the newest idea in this book with a name, and the literature is correspondingly thin and opinionated. The best material is either older — from API and service contracts — or is practitioner writing that has not yet settled.

On compatibility, from the source

The Apache Avro specification, "Schema Resolution." Recommended in Chapter 11 and mandatory here. It defines precisely what "compatible" means: which changes a reader with schema A can tolerate in data written with schema B, field by field, including the default-value rules that make optional-field addition work. Every entry in §17.2's table is derived from this section, and reading it once turns the table from something you memorize into something you can derive. Tier 1.
The Confluent Schema Registry documentation on compatibility types. The operational counterpart: what BACKWARD, FORWARD, FULL, and their _TRANSITIVE variants actually check, and — the useful part — a table of which changes each permits. Note that the transitive variants check against every prior version rather than only the latest, which for a replayable log is what you want. Tier 2 — versioned; the semantics have been stable but the docs move.
The Protocol Buffers documentation on "Updating A Message Type." A different evolution model — field numbers are the identity, names are not — and reading it alongside Avro's is the fastest way to see which compatibility rules are essential and which are one format's choice. Tier 1.

On the contract idea

Chad Sanderson's writing on data contracts, and the surrounding discourse of the mid-2020s. He is the person most associated with the term in the data community, and the material is the best available statement of the organizational case — that the problem is ownership and incentives rather than schemas. Read it for §17.7's material; be aware that a substantial part of the discussion is conducted by people selling contract tooling. Tier 2 — newsletter and blog posts; find the current home.
Andrew Jones, Driving Data Quality with Data Contracts (Packt, 2023). A book-length treatment from someone who implemented contracts at scale. More prescriptive than this chapter and stronger on the implementation detail — the schema-as-code, the CI integration, the generated infrastructure. Worth reading if you are actually building this. Tier 2 — check the edition.
The PayPal data contract template, published openly, and the Open Data Contract Standard (ODCS) that grew out of similar efforts. Concrete YAML schemas for what a contract contains. §17.4's seven sections are close to these; comparing them is a good way to find what this chapter left out. Tier 2 — actively evolving standards.

The older literature, which is better than its age suggests

Ian Robinson and the consumer-driven contracts pattern (2006), and Martin Fowler's write-up. The idea that a contract should be defined by what consumers actually use rather than by what a producer publishes, predating the data-contract discussion by fifteen years. §17.4's consumer list is this idea applied to data. Tier 2.
The Pact documentation and its "consumer-driven" framing. The service-testing implementation of the above. Its assumption — that both sides are internal and cooperating — is exactly where it differs from a data platform's usual situation, and §17.8's observed contract is what you do when that assumption fails. Tier 2.
Roy Fielding and the REST/hypermedia literature on evolvability, particularly the argument that a system should be designed so that clients tolerate change rather than requiring coordination. Philosophically upstream of everything in this chapter, and a useful corrective: the most robust answer to schema evolution is a consumer that does not break, which is easier to say than to build. Tier 2.
Martin Fowler on ParallelChange (also called expand-contract). The refactoring pattern §17.6 uses, stated generally. Short, and it makes clear that this is a general software-evolution technique rather than something specific to data. Tier 2.

Anything on Conway's law and on the relationship between team boundaries and system boundaries. §17.7's argument — that contracts fail socially — is Conway's law appearing at the data layer: a contract between two teams is a negotiation, and its technical form follows the organizational relationship. Tier 2 — the original 1968 paper is short and findable.
Anything on blameless postmortems, particularly Google's SRE material. §17.7's fourth fix — that a contract violation is an incident with a retrospective — only works if the retrospective is genuinely blameless. A violation log that reads as an accusation produces defensiveness, which is this chapter's first case study in reverse. Tier 1.

On the residual gap

Anything you can find on semantic drift detection. §17.9's first residual — a field's meaning changing while its type does not — is not well solved. The nearest available work is in data observability and distribution-shift monitoring, which detects the symptom rather than the cause. If you find something better, it is worth more than most of this list. Tier 2, and thin.

If you only read one thing

Read the Avro "Schema Resolution" specification — perhaps twenty minutes.

It is the ground truth under §17.2's table, and once you can derive the compatibility rules rather than remember them, you can reason about a schema change you have not seen before, in a format that is not Avro, and get it right.

Then, if you have a second hour, read Fowler on consumer-driven contracts. It is the idea that §17.4's consumer list implements, and it reframes the whole chapter: the contract is not what the producer publishes; it is what the consumers actually depend on. Those are different documents, and the second one is the useful one.