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

Most engineering references are organized for the author's convenience — by topic, alphabetically, by the structure of the underlying standard — and they assume you will read linearly or grep for a keyword. This guide is organized differently, because the thing it is trying to change is not what you know but what you decide. Every chapter 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's job is to name that fork, lay out the consequence of each branch across the axes that matter — cost, power, reach, latency, reliability, serviceability, schedule — and hand you the date-stamped numbers you need to choose. Reading the guide well means reading it the way you would use a decision instrument, not a textbook.

This chapter is the user's manual for that instrument. It explains the decision-and-consequence pattern that 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 is repeatedly asking you to produce (design-basis sheets, SU budgets, decision matrices, scorecards); and — most important for a field moving this fast — how to read the numbers: their vintage, their confidence, and the discipline of not letting a stale forecast drive an irreversible decision. We close on the altitude rule that keeps the guide navigable: a roadmap forward-pointer is a bullet, never a chapter.

The unit of this guide is the fork and its consequence, not the fact. A fact tells you that air cooling saturates near 41 kW per rack. A fork tells you that because air saturates there and a GB200 NVL72 draws ~132 kW, the moment you commit to that density you have also committed to direct-to-chip liquid, a plumbed hall, reinforced floors, 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 name the downstream cost of choosing wrong. When you see it, slow down. That is the chapter telling you where the money and the regret are.

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 branch the evidence favors — 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 the most 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 is the master variable that deterministically sets density, cooling, fabric, redundancy, and siting. 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.

Reading the guide is not the deliverable. The deliverable is 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.

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 air-cooling ceiling near 41 kW per rack, 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. Hardware specifications are semi-durable — a shipping GB200 NVL72 draws what it draws — but roadmap parts (Rubin, Rubin Ultra, the ~600 kW Kyber-class rack) are 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.

The discipline is concrete. Every volatile headline figure in the guide is logged, date-stamped, and caveated in the provenance register (the companion to this guide), so a critical number is always one click from its source, its vintage, and an honest note on how contested it is. Three classes of figure are flagged explicitly as contested — GPU economic-versus-book life, HBM4 pricing, and hyperscaler depreciation policy — because reasonable analysts disagree and the disagreement is itself load-bearing for the decision. When a contested figure drives one of your irreversible forks, the right 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.

A guide this large stays navigable only if it obeys one structural discipline, and it is worth stating because 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 metric stack is defined once in Chapter 15.1 and 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 downgrade volatile market numbers to direction. 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, not your memory, 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.