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. Readers act on exactly these figures, and they 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, where each canonical figure is one date-stamped record of its value, vintage, source and scope. Nearly every figure that drives a decision is one click from its origin, so you can re-check it before you act.

Unlike the other appendices, Appendix D is mostly a tool rather than prose: 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, and the provenance discipline behind it: one record per figure, supersession when records merge, scheduled re-check dates and a revision history on every record. It ends with a static crosswalk of the evidence behind 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 guide's volatile figures. Each entry is one metric. It holds the value and its kind (observed, forecast, estimate or derived), the scope, the as-of date, the source and nearly always a link to it, and a review date. Fragile or disputed figures also carry a caveat. The tool lets you do three things at the bench:

• Search by metric, value, value kind, scope or source. 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 names its source, and nearly every row links to it, 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. The figure in a Part 4 key-number block and its register row are one and the same record: fix the record and every linked display shows the new number. The words around that number are written by hand, though. A tile's label, and every comparison table, quiz, deck slide or chapter sentence that repeats the figure, stays as written when the record changes, so check each restatement against the record's scope. When two entries turn out to be the same fact in different clothes, one record supersedes the other and every reference follows the survivor. The publish gates block a page that points at a superseded record, and they block a new divergence between a record and any restatement the checker can match (known, reviewed divergences are baselined).

Read the entry's quantity, value, kind and scope, vintage, source and caveat, in that 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, and the register's next scheduled review is December 22, 2026. The receipt keeps the 54-day population on up to 16,384 H100s: 419 unexpected of 466 total interruptions, with 148 faulty-GPU and 72 HBM3 events. The derived interruption shares use those counts.

The receipt tells you how to read that 54-day training window. It does not give a GB300 annual failure rate, so don't size GB300 spares from it until the new fleet's component exposure and duty match. For a licensed standard, attach the exact clause you actually opened and the project's access record: a catalog's edition date establishes identity, not the contents of a clause you have not opened. Chapter 14.3 owns the failure evidence and Appendix A identifies standards. Source: Meta, §3.3.4 / Table 5.

Before a figure drives a decision, classify it, then constrain how you may use it. These three classes are a reading rule; the volatility tag on each register record sets only how often it is re-checked (fast, standard or slow).

• Durable (physics, standards, thermodynamics): design against the level, but keep its scope. A cited 30–40 kW typical RDHx range and a >50 kW active-door example are not universal air-cooling limits; test the specific door against your facility's water and air conditions. → 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.

The register flags a figure CONTESTED wherever reasonable analysts disagree and the disagreement itself carries weight. The contested set includes fabric oversubscription, revenue per GW of contracted IT, hyperscaler depreciation policy, and GPU economic-versus-book life with its residual value. When a contested figure drives an irreversible fork, don't pick a point estimate. Run the decision across the plausible range and confirm the branch holds wherever the number lands. → the discipline is set out in Chapter 1.8.

Each record carries a review date, set explicitly or derived from its cadence (fast: 30 days, standard: 120 days, slow: a year). The date schedules a re-check; it does not record one, so log 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. The change shows in that claim's revision history on the register and in the guide's updates, so the register's own history is auditable. The public corrections page lists only corrections that readers submitted and the guide accepted.

One figure-set separates reproducible arithmetic from disputed earning assumptions: the GPU useful-life debate from 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 applies exactly 3, 5 and 7 IT years (the workbook default is about 5.3), and its linked cost totals and three-versus-seven premium of about 70% use unrounded Epoch workbook inputs. This is an earning-life scenario, not a change in cash caused by book depreciation. Model book life and economic life, and disclose which one your covenants assume.