The Requirements-and-Consequences Matrix

Chapter 1.1 established the governing input — the workload archetype — and walked the cascade qualitatively. Here it becomes an engineering instrument: a requirements-and-consequences matrix that takes one archetype and returns a concrete, numbered design basis for every subsystem that follows. Where 1.1 said "pre-training implies liquid cooling," this chapter says which inlet temperature, which flow rate, which floor-loading class, which blocking ratio, which storage throughput floor, and which redundancy tier — along with the downstream cost of each cell you fill in wrong.

The altitude here is lower than in 1.1. We move through four mappings in the order an engineer actually commits them — density to the cooling cliff, fabric and the GPU:CPU/memory/storage ratios, storage and redundancy against interruption tolerance, and siting as power-first versus latency-first — and close on the reference design-basis sheets that capture all four per archetype. Read this chapter with Chapter 1.1 open: this is the table its cascade was promising.

The first irreversible commitment is the cooling-service envelope. Peak rack density is one input alongside the liquid heat fraction, airflow and inlet limits, TCS/FWS availability, climate and rejection method, residual room heat, redundancy, serviceability, and the future density tail. Conventional air, close-coupled air, water-fed rear-door heat exchangers (RDHx), hybrid systems, and direct-to-chip liquid overlap rather than switching at universal kW thresholds. RDHx can extend an existing air architecture by bringing chilled or tempered water to the door. An AALC or in-rack L2A sidecar closes the local liquid loop against room air instead, trading the door water drop for additional room-air heat rejection. Direct-to-chip liquid (DLC) becomes the normal path when the named rack profile and heat flux require liquid capture at the source. A GB200 NVL72 draws ~120–132 kW — roughly ~115 kW removed by liquid and ~17 kW by residual air — which explicitly defines a liquid-plus-residual-air architecture. GB300 NVL72, the 2026 volume rack platform, carries the same architecture at ~132–140 kW. The ramp does not soften it: VR200 NVL72 entered full production in August 2026 at ~190–230 kW (analyst estimate: Kuo / Hashrate Index, 2026), and Rubin Ultra Kyber is on a ~600 kW / 800 VDC path. Rack density narrows the feasible set, but the complete named equipment and facility envelope selects the cooling service.

The consequence of qualifying only rack kW is a false answer: two racks at the same draw can require different services because their heat split, flux, airflow/inlet limits, water interfaces, and room residual differ. Where a future profile requires liquid and the inherited hall lacks structure, distribution, isolation, CDU space, or heat rejection, retrofit can cost ~$5–6M/MW and still strand capacity. The matrix below records the evidence that rules each path in or out; the engineering lives in Chapter 5.1 through Chapter 5.4.

The second mapping is the network, and it has two parts: the blocking ratio of the back-end (scale-out) fabric, set by coupling, and the system composition ratios — GPU:CPU, GPU:memory, GPU:storage — set by the archetype's host-side and data-path demands. Both are decisions where the wrong answer wastes money in opposite directions: over-build and you pay for bandwidth that never carries traffic; under-build and you starve the accelerators you spent the most on.

Measured coupling sets the blocking ratio. Published fabrics span 1:1, 2:1–3:1, and reported 7:1 examples across different tiers and populations. Derive the ratio per tier from the measured traffic matrix, collective/request mix, placement and communication overlap, topology, failure headroom, and step-time or tail-latency SLO. Synchronous collectives often justify high bisection; local inference often permits upper-tier oversubscription, while distributed MoE and KV movement can demand more. A named 2:1 model estimates roughly one-third lower back-end cost, but the workload label alone does not earn that saving. → Chapter 8.5 (topology & oversubscription), Chapter 8.4 (protocols).

The composition ratios are archetype-specific and shifting. Training historically ran ~4–8 GPU:1 CPU; agentic inference — with host-side sandbox execution, retrieval, tool calls, and RL rollouts — is pulling that toward ~2:1 and below (Intel reports 8:1 → 1:1), which changes the host BOM and the node power budget. GPU:memory is set by per-GPU HBM (H100 80 GB → B200 180 GB → B300 288 GB → Rubin Ultra ~1 TB) plus host RAM, and inference is increasingly KV-cache-bound rather than weight-bound. GPU:storage is a bandwidth ratio, not a capacity one: it is fixed by checkpoint write speed for training and data-loader read speed for both — which is exactly where Mapping 3 begins.

Storage and redundancy are two consequences of the same input — the archetype's tolerance for an interrupted GPU — and they are most defensible when designed together. The question storage answers is: when does a GPU stall waiting on data, and what does that stall cost? The question redundancy answers is: when a node or a power feed fails, does the workload restart cheaply or lose money?

Storage is sized by the throughput that keeps GPUs fed, not by capacity alone. For training, the two binding flows are checkpoint write bandwidth — because a synchronous job pauses all GPUs to write a checkpoint, and slow writes are pure goodput loss — and data-loader read bandwidth, because a starved loader idles the whole pipeline. A high-bandwidth parallel file system feeding GPUDirect Storage (CPU-bypass) is the training default; this is the link that turns a storage decision into a GPU-efficiency decision (Chapter 9.1, Chapter 9.3, Chapter 9.4). For online inference, the new pressure is the KV-cache: reasoning models emit long decode sequences, inflating per-request cache, so the hierarchy now tiers KV state across HBM, host memory, and NVMe/CXL (Chapter 9.7). Batch and edge are the relaxed cases — throughput reads with no low-latency floor.

Redundancy is set by interruption tolerance, and over-building it is a recognizable waste. A synchronous training job already restarts from a checkpoint when any node fails — SemiAnalysis reported ~7 days of MTBF for one 512-H100 cluster at a top-tier operator, while Meta's separate Llama 3 405B run logged ~one interruption every three hours on 16,384 H100s; these differently defined observations are not one scaling curve — so a single-path or component-redundant posture is viable when checkpoint recovery meets the service objective (Chapter 1.1's over-provisioned-redundancy anti-pattern — stronger topology must earn its cost through a required outcome). An always-on inference business often inverts this: when maintenance or one component fault would breach the SLA and lose revenue, require no load loss for either event. → Chapter 12.1 (redundancy topologies), Chapter 12.2 (goodput vs availability), Chapter 12.4 (goodput SLAs).

The fourth mapping is the least reversible of all — you cannot move a slab — which is why it must be derived from the workload, never chosen first and rationalized after. Latency sensitivity is the discriminator. Pre-training and batch inference are indifferent to user proximity, so they are scored power-first: chase the cheapest firm (or curtailable) megawatts and the coldest free-cooling climate, accept that the site may be hours from any metro, and treat the grid-interconnection queue slot as the scarcest asset in the project. Online and edge inference are scored latency-first: chase sub-50 ms reach to users and accept power that can cost 2–4x more, distributing capacity for proximity rather than concentrating it for cost.

The 2026 context sharpens this fork. The binding constraint is often power, not chips. Because large-load service dates are utility-, tariff-, study-, upgrade- and project-specific, a power-first archetype that mis-sites near expensive, constrained metro power burns both money and a queue slot it cannot recover. A latency-first archetype sited in a cheap-power exurb, conversely, may meet its energy budget and miss its SLO, which is the more expensive miss because it loses the revenue the building exists to earn. Water availability is a hard siting gate for any liquid-cooled hall regardless of archetype (Chapter 3.7). The reordered hierarchy and the speed-to-power race are engineered in Chapter 3.1 and Chapter 3.2; the fiber/latency screen in Chapter 3.6.

The four mappings converge into a single artifact: a reference design-basis sheet per archetype that freezes the inherited assumptions before any long-lead equipment is ordered. This is the deliverable 1.1 promised under "design-basis document," now filled in. Each sheet pins one row per subsystem — density tier, cooling modality, fabric blocking ratio, system ratios, storage tier and throughput floor, redundancy topology, voltage class, and siting class — plus a reversible-vs-irreversible register recording which assumptions are hedged and which are committed. The table below is the skeleton; a real sheet attaches the numbers (the ramp curve, the MVA sizing, the CDU capacity) and the signatures.