Further Reading: Capstone

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 different note for this chapter. The capstone has almost no literature of its own, because "reconcile your platform to its source" is not a topic anybody writes a book about — it is what accountants have done for six hundred years and what data teams mostly do not do at all. So the reading below is deliberately lopsided: a little from accounting, a little from testing, and a great deal from this book, because the capstone is the assembly of thirty-seven chapters rather than a new subject.

Read the accounting, briefly

Any introductory financial accounting text, on the reconciliation and the trial balance. Two hours, and it will reframe what you are doing. Double-entry bookkeeping is a reconciliation mechanism invented in the fifteenth century, and its core insight — that a system which records every fact twice, in two independent ways, catches errors a single record cannot — is §38.8's argument, six hundred years earlier. Tier 1 — any standard text; you need one chapter.
Anything on revenue recognition, particularly the treatment of gift cards and refunds. §38.5's R3 and R4 are standard accounting rules that engineers get wrong, and the reason to read this is not to make the decision but to know that a decision exists. Case Study 1's third failure was an engineer reasonably concluding that a line item with a price is revenue. Tier 2 — IFRS 15 / ASC 606 summaries are readable; the standards themselves are not.
Your own finance team. An hour, and it is worth more than anything on this list. Bring the four rules and ask which ones they own — the answer at Kestrel was three of four, and nobody had asked.

On the verification argument

Chapter 34 §34.9 and Chapter 36 §36.10 of this book. The rebuild and the replay. §38.9 is the same idea applied to the whole platform, and Case Study 2's three defects are the three those chapters predict.
Anything careful on property-based testing. The capstone's strongest assertions are properties, not examples: the two ratios must agree, the peak must fall on the right day, the rebuild must equal the original. Hypothesis (Python) documents the mindset well even if you never use the library, and the shift from "assert this output" to "assert this invariant" is what §38.13's shape assertions are. Tier 1.
Anything on reproducible builds — the Reproducible Builds project in software packaging is the most developed version. Their central claim, that a build which cannot be reproduced cannot be audited, is Case Study 2's §"Design Decision" in a different field, and they are far more rigorous about it than the data community is. Tier 1.
Kent Beck and others on "make it work, make it right, make it fast." Relevant backwards: the capstone argues you should make the verification work first (§38.14), which inverts the usual order and is the chapter's one genuinely contrarian claim. Tier 2 — folklore with good provenance.

On the handover

Anything on runbooks and operational readiness reviews. Google's SRE material has the best-known version, and the "production readiness review" checklist is §38.12's six artifacts with different names. Tier 1.
The literature on documentation that gets read — Diátaxis is the most useful framework, because it distinguishes tutorials, how-to guides, reference, and explanation, and most data platform documentation fails by mixing them. §38.12's five questions map cleanly onto it. Tier 1.
Anything on "bus factor" and knowledge transfer. §38.12's test — hand the README to someone who has not seen the project and watch without helping — is the cheapest and most reliable measurement in this literature, and almost nobody runs it. Tier 2.

On the parts of the book this chapter assembles

This is the honest bibliography for a capstone, and each entry is the chapter whose machinery §38 depends on:

Chapter 1 §1.7 — the acceptance criterion, and the frozen anchors that §38.7's verification checks against.
Chapter 20 — incremental models and the deterministic tie-break Case Study 2's first defect violated.
Chapter 23 — the assertion register, and §38.11's honest reading of what it caught.
Chapter 26 — the SLO and the slack that §38.10 publishes.
Chapter 27 — the CI that runs the models, and where purity.py belongs.
Chapter 30 — the catalog, without which §38.12's second question needs a person.
Chapter 31 — the deletion manifest, without which the platform is not finished.
Chapter 33 — the rate card §38.10 prices against, and the slack alert.
Chapter 34 §34.9 — the rebuild.
Chapter 36 Case Study 1 — reconciliation independence, which is §38.7's and §38.8's whole argument.
Chapter 37 §37.7 — a difference is usually a rule nobody wrote down, which is Case Study 1 four times over.

Practice

code/capstone.py. Thirty-eight assertions, including the two that check the result against Chapter 1 rather than against itself. Run --self-check before reading §38.7.
Reconcile something real. Exercise 38.12. Write down every rule before you run the comparison, then count how many you missed. Kestrel missed four of four.
Rebuild and diff row by row. Exercise 38.5. A rebuild that succeeds first time usually means you rebuilt from something already materialized.
Hand your README to someone. Exercise 38.9. Watch, do not help, and write down every point at which they stop.
Write the "not done" list. Exercise 38.10. If it is empty, you have not looked.

A note on what to be skeptical of

Any platform described as "done" without a reconciliation. Done against what? A pipeline that runs is not a pipeline that is right, and four months of green is what Chapter 38's opening quotation is about.

Any reconciliation with a tolerance. Against an external source with genuine irreducible differences (Chapter 37), a documented tolerance is correct. Against your own source database it is a decision to stop looking.

Any capstone — including a portfolio project — that reports only success. §38.13 exists because a retrospective without failures has hidden them, and an interviewer reading a project write-up looks for exactly that (Chapter 39).

And any claim of reproducibility that has not been tested twice. Case Study 2's rebuild reproduced three times before failing, which was worse than never having run it.