How to Read This Guide: Decisions, Consequences & Reference Data

Every chapter here is built around a fork: a point where a real project commits to one branch over another, where the branches pull the rest of the facility in incompatible directions, and where choosing wrong is expensive or irreversible. The chapter names that fork, lays out the consequence of each branch across the axes that matter — cost, power, reach, latency, reliability, serviceability, schedule — and hands you the date-stamped numbers you need to choose. Most engineering references are organized for the author's convenience — by topic, alphabetically, by the structure of the underlying standard. This one is organized around what you have to decide, and that changes how it should be read.

What follows is the user's manual. It covers the decision-and-consequence pattern every chapter follows; the three orthogonal navigation paths — by lifecycle stage, by engineering discipline, by workload archetype — and how to pick the one that matches your job today; the reference artifacts the guide repeatedly asks you to produce (design-basis sheets, SU budgets, decision matrices, scorecards); and, because the field moves fast, how to read the numbers: their vintage, their confidence, and the habit of keeping a stale forecast away from an irreversible decision. We close on the altitude rule that keeps the guide navigable: a roadmap forward-pointer is a bullet, never a chapter. Leave the chapter with a chosen branch, its acceptance evidence, an accountable owner and the input that would reopen it.

The unit of this guide is the fork and its consequence. A fact tells you that cooling capacity depends on airflow, inlet conditions, heat capture, water availability, climate, and equipment limits. A fork tells you that because the cited HPE GB200 profile removes ~115 kW in liquid and leaves ~17 kW to air, committing to that product commits you to its supported direct-to-chip and room-air architecture, a plumbed hall, a floor proven for the rack and its delivery route, and a heat-rejection strategy — and that this particular commitment is a one-way door. Every chapter is written to surface that second kind of statement: name the fork, then the downstream cost of choosing wrong. When you hit one, slow down; that is where the money and the regret concentrate.

The pattern shows up in three physical forms on the page, and learning to read each one quickly is most of what it takes to use the guide efficiently. Decision callouts (the boxed asides) isolate a single high-leverage fork and state the condition under which the evidence favors a branch — these are the chapter's load-bearing claims, and if you read nothing else in a chapter you should read its decision callouts. Decision tables put the branches in rows and the consequences in columns, so you can scan across the one branch you are leaning toward and read its full bill of consequences at once. Cross-references (the inline chapter links) mark where a consequence is derived rather than asserted — when a fork hinges on a number you do not trust, follow the link to the chapter that builds it.

The guide can be entered from three orthogonal directions, and a common mistake is reading it from the wrong one for the question you actually have. The three indices do not contradict each other — they are three projections of the same material — but they put different chapters in front of you first, and starting from the wrong projection wastes time and, worse, hides the fork you came to resolve.

By lifecycle stage is the spine, and the default. The Parts run in the order a real project runs: strategy and delivery, then siting, power, electrical, cooling, the building, compute, networking, storage, software, security and reliability, commissioning, operations, sustainability, and the future. If you are at a stage — you have a site and you are sizing the power chain — read the corresponding Part top to bottom; the chapters are sequenced so that each decision is teed up by the one before it. This is the right path for project teams executing in order.

By engineering discipline cuts across the spine. If you own cooling, the decisions you live with are scattered across Part 1 (the archetype that sets your density), Part 5 (the thermal engineering itself), Part 13 (commissioning the plant), and Part 14 (operating it). The cross-reference links are the connective tissue for this path: follow them and you assemble a discipline-shaped reading list out of a stage-shaped book. This is the right path for specialists who go deep on one subsystem across every project.

By workload archetype is the path for strategists and anyone scoping a new facility, because — as Chapter 1.1 argues at length — the workload sets the requirements that density, cooling, fabric, redundancy, and siting must meet; the label alone never selects a topology, the measured envelope it implies does. Start from your dominant archetype (pre-training, post-training/RL, online inference, batch inference, edge), read the cascade it implies, and let that cascade tell you which discipline chapters you are now forced to care about. This is the right path when the facility does not exist yet and the question is what to build.

Using this guide produces a small set of artifacts that the chapters repeatedly ask you to fill in — durable documents that survive board scrutiny and lender diligence because they pin down a decision and its consequences in a form someone else can audit. Four recur throughout, and recognizing which one a chapter is asking you to produce is half of using it well.

• Design-basis sheet. The frozen assumptions everything downstream inherits: density tier, cooling modality, redundancy topology, voltage architecture, siting class, and the reversible-vs-irreversible register that records which assumptions are hedged and which are committed. One per facility (or per hall). It is the contract between the workload decision and every subsystem. Per-archetype reference sheets are built in Chapter 1.7.
• Scalable-unit (SU) budget. The repeatable building block — a defined quantum of compute, power, cooling, and fabric (a pod, an NVLink-domain-aligned block) with its power, space, weight, water, and cost rolled up — that you replicate to scale a facility. Scoping in SUs, rather than in raw GPU counts, is what makes a capacity ramp tractable. The SU vocabulary is defined in Chapter 0.3.
• Decision matrix. The branches-by-consequences table you lift straight out of a chapter's decision tables and adapt to your weights. It is how a fork becomes a defensible choice on paper: branches in rows, axes (cost, power, reach, latency, reliability, serviceability, schedule) in weighted columns, the chosen branch and its rejected alternatives recorded.
• Scorecard. The quantitative roll-up that scores a completed scope — a site-scoring playbook output (Chapter 3.13), an ROI scorecard (Chapter 1.8), an availability/goodput number (Chapter 12.5). Where the matrix chooses a branch, the scorecard grades the whole.

When a chapter hands you a table, ask which artifact it feeds. Most decision tables feed a decision matrix; most keynumbers blocks feed an SU budget or a scorecard; most callouts feed the design-basis sheet's irreversible register. The guide is, in effect, a long set of instructions for assembling these four documents.

Screen: IT load = 4 × 2 × 12 + 4 = 100 kW. Coincident facility demand = 100 + 28 = 128 kW, leaving 160 − 128 = 32 kW of service headroom; heat-removal headroom is 120 − 100 = 20 kW. The fifth rack adds 24 kW: 152 kW fits the electrical service, but 124 kW exceeds heat removal by 4 kW. It fails the screen even though the electrical meter has room. Annual PUE has not entered this peak-capacity test.

Price reversibility: call the displayed reservation cost R, reserved upgrade U and unreserved retrofit F. Expected present cost of reservation = R + 0.50U/(1.10)², about $130k. Waiting costs 0.50F/(1.10)², about $170k. Reserve the route under these assumptions, saving about $40k in expected present cost; do not buy or sell the fifth rack’s cooling capacity yet. The crossover is p = R(1.10)²/(F − U), about 30%. Below that expansion probability, waiting is cheaper; at 20%, reservation costs about $90k against about $70k for waiting. A route that cannot carry the upgrade fails regardless of price.

The four artifacts now have content: the design basis states the 100 kW IT boundary and 128 kW facility demand; the scalable-unit budget counts eight nodes across four racks; the decision matrix selects route reservation against waiting; the scorecard marks the fifth rack’s cooling as failed and physical feasibility as HOLD pending survey. The service owner must obtain the demand case, and the facility engineer the route and capacity evidence before purchase. This is an orientation screen. Chapter 1.7 owns the full basis, Chapter 5.1 the heat boundary, and Chapter 1.8 the cash comparison. Epoch’s capital-recovery method supplies the primary time-value reference; the assumed prices are guide inputs.

The figures in this guide span three very different half-lives, and treating them as if they were equally durable is how teams anchor an irreversible decision to a number that was already obsolete when the ink dried. Read every figure through its as-of date and its confidence caveat first, and the value second.

Physics and standards are durable. The thermodynamics of a delta-T across a cold plate, the availability algebra of serial-versus-parallel composition — these do not move on a quarterly cycle. When a chapter cites them you can treat them as levels and design against them directly. Rack-cooling selection is an engineering envelope, not a universal kW threshold: verify airflow and inlet limits, liquid heat fraction, water-system interfaces, climate, residual room heat, serviceability, redundancy, and the future density tail for the named equipment profile (Chapter 5.1). Hardware specifications are semi-durable: a shipping GB300 NVL72 draws what it draws, and the VR200 NVL72 racks that entered full production in August 2026 are a near-term part you can schedule against as their volume ramps into 2027 (NVIDIA Q2 FY27 earnings, 2026-08-26). Rubin Ultra and its ~600 kW Kyber-class rack remain announced, not shipping, and every such figure in this guide is marked as roadmap precisely so you do not budget against a number that may slip a generation. Market and economic figures are volatile: rental rates, colocation pricing, capex forecasts, depreciation policy, and interconnection-queue depth can move 30–40% in two quarters. Read these as direction and order of magnitude, never as a level you can underwrite, and re-check them against a live source before they drive a financial decision.

Every volatile headline figure in the guide is therefore logged, date-stamped, and caveated in the Numbers Register (Appendix D), so a critical number is always one click from its source, its vintage, and an honest note on how contested it is. Some figures are flagged explicitly as contested — GPU economic-versus-book life, hyperscaler depreciation policy, and liquid-cooling retrofit capex among them — because reasonable analysts disagree and the disagreement is itself load-bearing for the decision. When a contested figure drives one of your irreversible forks, run the decision across the plausible range rather than a point estimate, and confirm the branch is robust to where the number actually lands.

A guide this large stays navigable only if it obeys one structural discipline, and it shapes how you read the forward-pointers. A roadmap forward-pointer is a bullet, never a chapter. When a chapter says "this density trend continues toward 1 MW racks," that is a one-line signpost — read it as orientation, do not expect the chapter to derive it, and do not go looking for a roadmap chapter that does not exist. The per-part roadmaps — the consolidated 2026 to 2030 subsystem trajectories — live in exactly one place, Chapter 16.2, so that the forward-looking material does not metastasize across forty chapters and rot independently in each. Every other chapter points forward with a bullet and sideways to its canonical derivation with a cross-reference.

This is the same single-source-of-truth discipline that governs the whole guide: a concept is defined once, in its canonical home, and referenced everywhere else. The facility metric stack is defined once in Chapter 15.1 and the useful-work metrics in Chapter 14.1, both merely oriented in Chapter 0.3; the redundancy vocabulary is primed in Chapter 0.5 and engineered in Chapter 12.1; the standards landscape is indexed in Chapter 0.4. When you hit a term defined elsewhere, the cross-reference is telling you that this chapter is consuming a definition it does not own, and that if you distrust the definition you should follow the link rather than re-derive it locally. Read the cross-references as the dependency graph of the guide, and you will always know where the authoritative version of any claim lives.

Put the pieces together into a protocol you can run on any chapter. One: read the thesis and the decide list, and ask whether this chapter bears on a fork you actually own — if not, move on; the guide is not meant to be read whole. Two: for each fork it does raise, classify it on the reversibility axis before you let any number drive it. Three: read the decision callouts as the chapter's central claims, and scan the decision tables across the branch you are leaning toward. Four: before lifting any figure into an artifact, check its as-of date and caveat, and test volatile market numbers as dated ranges. Five: when a consequence is asserted rather than derived and the fork is yours, follow the cross-reference to the canonical chapter. Six: capture the outcome in the right artifact — design-basis sheet, SU budget, decision matrix, or scorecard — because the artifact, including its owner, acceptance evidence and reopening trigger, is the durable output. Run that loop and the guide does what it is for: it turns a fast-moving, power-bound, multi-disciplinary build into a sequence of well-posed, well-dated decisions.