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, the branches pull the rest of the facility in incompatible directions, and choosing wrong is expensive or irreversible. The chapter names the 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 to read it.

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 yours; 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. It ends with 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, the test that proves it works, 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, facility water if the liquid loop rejects there (an air-assisted sidecar rejects to room air instead), a floor proven for the rack and its delivery route, and a heat-rejection strategy, and that this 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 appears in three forms on the page, and reading each 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. They are the chapter's load-bearing claims, so if you read nothing else in a chapter, read these. Decision tables put the branches in rows and the consequences in columns, so you can scan across the 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 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 one wastes time and 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, say you have a site and you are sizing the power chain, read the corresponding Part top to bottom; each chapter tees up the decision in the next. 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: 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. 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 requirements it implies do. 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 for 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. Keep one per facility (or per hall). It sets what the workload decision requires of every subsystem. Per-archetype reference sheets are built in Chapter 1.7.
• Scalable-unit (SU) budget. The repeatable building block you replicate to scale a facility: 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. Scoping in SUs rather than raw GPU counts makes a capacity ramp tractable. The SU vocabulary is defined in Chapter 0.3.
• Decision matrix. The branches-by-consequences table you lift from a chapter's decision tables and adapt to your weights. It turns a fork into a defensible choice on paper: branches in rows, axes (cost, power, reach, latency, reliability, serviceability, schedule) in weighted columns, and 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 records 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 over waiting; the scorecard marks the fifth rack’s cooling as failed and physical feasibility as open until a site survey confirms the route. Before anyone buys, the service owner confirms the demand case and the facility engineer surveys the route and its capacity. 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 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 and the availability algebra of serial-versus-parallel composition 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 limit, not a universal kW threshold: for your equipment, verify airflow and inlet limits, liquid heat fraction, water-system interfaces, climate, residual room heat, serviceability, redundancy and the future density tail (Chapter 5.1). Hardware specifications are semi-durable. A shipping GB300 NVL72 draws what it draws, and the VR200 NVL72 racks shipping since June 2026 (Dell's first racks went to CoreWeave) are a near-term part you can schedule against: NVIDIA reported racks running at CoreWeave, Google Cloud, Microsoft Azure, OCI and Nebius as Vera Rubin ramped into full production (Q2 FY27 results, 2026-08-26). Confirm your allocation date with the OEM. Rubin Ultra and its ~600 kW Kyber-class rack remain announced, not shipping, and every such figure in this guide is marked as roadmap 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 by tens of percent within a year. Dell'Oro's outlook for 2030 data-center capex, now more than $3T, nearly doubled between its January and August 2026 forecasts. 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 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, among them GPU economic-versus-book life, hyperscaler depreciation policy and liquid-cooling retrofit capex, because reasonable analysts disagree and the disagreement is itself load-bearing. 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 lands.

A guide this large stays navigable only if it obeys one structural rule, and the rule shapes how you read 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 look 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 the forward-looking material does not spread 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.

The same single-source discipline governs the whole guide: a concept is defined once, in its canonical home, and referenced everywhere else. The facility metric stack is defined 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 tells you 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 the chapter bears on a fork you 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, with its owner, acceptance test 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.