Numbers Provenance & Forecast Register

This guide is full of numbers that move. Rack power, capex totals, GW of grid demand, $/GPU-hour, depreciation lives, TWh forecasts — these are the figures readers actually act on, and they are exactly the figures that go stale fastest. A printed reference freezes them at press time and quietly misleads everyone who reads it a year later. This appendix is the reader's door into the guide's claim library: every canonical figure is a single date-stamped record — value, vintage, source and a direct link, scope, and an honest caveat on how contested or fragile it is — and linked key-number displays resolve that record by reference; an independently written sentence, table or exported copy still needs its own check. Every figure that drives a decision is one click from its origin, so you can re-check it before you act — the discipline a frozen print reference cannot offer.

Unlike the rest of the appendices, Appendix D is not primarily prose — it is realized as an interactive tool in the site: a searchable, part-filterable table over the same claim records that power the inline figures throughout the guide. This page explains what the tool does, how to read an entry, the provenance discipline behind it — one record per figure, supersession when records merge, scheduled re-check dates, a public corrections log — and the static evidence crosswalk for the contested depreciation inputs carried over from Chapter 1.8. For the live data, open the tool.

The register is a single source of truth for the volatile figures in this guide. Each entry is one metric — a value, the date it was true, the source, a link, the scenario it assumes, and a caveat. The tool lets you do three things at the bench:

• Search by metric, value, source, or caveat text — type "depreciation," "interconnection," or "HBM" and the table narrows live.
• Filter by part — narrow the table to any Part of the guide or to the appendices, or to the curated register and the regulatory watchlist; a separate control shows only the contested figures.
• Verify — every row carries an as-of date and a source link, so re-confirming a number against its primary publication is one click, not a research project.

Each row is a claim — the guide's unit of factual record. Chapters’ linked key-number blocks resolve the dated record; comparison tables, quizzes and presentation decks also contain authored explanations that must be checked against the same scope. So a figure you read in Part 4 and the same figure in the register are literally one record: correct the record, then verify each linked display and authored restatement. When two entries turn out to be the same fact in different clothes, one record supersedes the other and every reference follows the survivor — and the publish gates refuse to ship a page that points at a superseded record or restates a figure that has drifted from it.

Read the entry’s quantity, value, vintage, scenario, source and caveat in this order. Then attach the evidence receipt: exact document version and locator, access obtained, date checked, and next planned review. A date alone proves none of the underlying checks.

A completed evidence receipt. Meta’s The Llama 3 Herd of Models, arXiv v1, July 31, 2024, §3.3.4 and Table 5, is publicly accessible. The guide checked that exact passage on September 8, 2026; the register’s next scheduled review is December 22, 2026; that date does not prove a human will review it. The receipt retains the 54-day, 16,384-H100 population: 419 unexpected interruptions, with 148 faulty-GPU and 72 HBM3 events. The derived interruption shares use those counts; they do not turn into a GB300 annual failure rate.

Accept that receipt when interpreting the named training window. Reject its use to buy GB300 spares until component exposure and the new fleet’s duty match. For a licensed standard, attach the exact clause actually opened and the project’s access record; a catalog’s edition date establishes identity, not the contents of an unseen clause. Chapter 14.3 owns the failure evidence and Appendix A identifies standards. Source: Meta, §3.3.4 / Table 5.

The register enforces one rule before a figure is allowed to drive a decision: classify it, then constrain how you may use it.

• Durable (physics, standards, thermodynamics) — design against the level. Thermodynamic relationships and adopted standards can be durable, but a cited 30–40 kW typical RDHx range and >50 kW active-door example are not universal air-cooling limits; test the named equipment and facility envelope. → Chapter 0.3.
• Semi-durable (shipping hardware specs) — use the level, but confirm the part actually ships on your timeline. A roadmap rack power is not a procurable one.
• Volatile (market, capex, rental rates, forecasts) — use the direction, and re-pull a live number before committing. Cross this with the reversibility lens: a volatile figure driving a reversible decision is fine; a volatile figure driving an irreversible one is the trap.

Figures are flagged CONTESTED in the register wherever reasonable analysts disagree and the disagreement is itself load-bearing: GPU economic-versus-book life and residual value, hyperscaler depreciation policy, revenue per energized GW, self-operated TCO at scale, and fabric oversubscription among them. When a contested figure drives an irreversible fork, the correct move is not to pick a point estimate — it is to run the decision across the plausible range and confirm the branch is robust to where the number actually lands. → the discipline is set out in Chapter 1.8.

A volatility class can schedule a re-check — monthly, quarterly or annually — but that schedule is an assignment, not evidence of a human review. Record who checked which passage and when; a passed check changes the verification receipt, not the source vintage: a 2024 measurement re-verified in 2026 is still a 2024 measurement, and the as-of date says so. When a figure fails a check, it is corrected at the record rather than padded with a disclaimer, and the change is logged on the guide's public corrections page, so the register's own history is auditable.

One figure-set separates reproducible arithmetic from disputed earning assumptions: the GPU useful-life debate bound out of Chapter 1.8. Some operators book AI servers over 5–6 years. Goldman Sachs estimates a 4–6 year useful life; the 2–3 year case is a contested obsolescence bear case, not an observed universal economic life. The fixed-input 1 GW sensitivity in Chapter 1.8 compares exactly 3 and 7 IT years; its linked cost totals and premium use unrounded Epoch workbook inputs. This is an earning-life scenario, not a change in cash caused by book depreciation. The honest posture is to model both lives and disclose which one your covenants assume.