Appendix A
Standards & Specifications Cross-Reference Matrix
There is no single global standard for an AI data center — there is a stack of overlapping resilience, thermal, efficiency, hardware, and compliance regimes from different bodies that do not map one-to-one. This appendix is the crosswalk: the tables you reach for when a spec, a tier letter, a class number, or a framework name shows up in a contract, an RFP, or a commissioning script and you need to know what it is, what it maps to, and whether it actually applies to a 2026-density liquid-cooled hall.
What you'll decide here
- Find the row, not the prose. Each table is keyed on the term you already have — a Tier numeral, an ASHRAE class, a KPI acronym, an OCP project name, a framework — so you can land on the right row from a contract clause or a vendor datasheet and read across.
- Treat the resilience crosswalk (Uptime ↔ TIA-942 ↔ EN 50600 / ISO 22237) as approximate, not equational. The bodies certify different things (topology vs full-facility vs management system) and explicitly disclaim equivalence; use the mapping to translate intent, then verify against the actual standard text before you commit it to an SLA.
- Use the AI-relevance column in the thermal and OCP tables as the filter. Many legacy classes (air A1–A4, ORv2) describe a world below the density wall; the rows that matter for GB200-class and beyond are flagged.
- Cross-check every figure against its asof date before quoting. Standards revise (TIA-942-C is May 2024; ASHRAE Thermal Guidelines are 5th ed.) and OCP specs version fast (Diablo 400 was v0.5.2 in mid-2025); a stale edition is a wrong answer.
- For deeper treatment, follow the chapter xrefs: the standards landscape lives in Chapter 0.4, the resilience design-basis in Chapter 0.5 and 12.1, the thermal envelope in Chapter 5.1, the metric stack in Chapter 15.1, and compliance/certification in Chapter 11.11.
An AI data center is governed by no single document. It sits at the intersection of at least five independent standards regimes, each maintained by a different body, each answering a different question, and none of which was written with 132 kW liquid-cooled racks in mind: resilience (Uptime Institute, ANSI/TIA-942, EN 50600 / ISO/IEC 22237), thermal (ASHRAE TC 9.9), efficiency KPIs (ISO/IEC 30134), open hardware (the Open Compute Project), and security & compliance (SOC 2, ISO/IEC 27001/42001, FedRAMP, CMMC, NERC CIP). They overlap, they conflict at the edges, and practitioners routinely treat them as interchangeable when they are not.
This appendix is the reference layer for that mess. It is tables, not argument. Where a number is volatile or vendor-sourced it carries a source and an asof date; where a mapping is approximate it says so, because a common standards error is asserting that a Uptime Tier "equals" a TIA Rated level or an EN 50600 Availability Class. They are cousins, not synonyms. Read the rows; verify against the standard text before it lands in a contract.
1. Resilience crosswalk: Uptime Tier ↔ TIA-942-C Rated ↔ EN 50600 / ISO 22237 Availability Class
Three regimes describe "how reliable is the facility," and they are not equivalent. Uptime Institute Tier I–IV certifies design topology and operations against a concurrent-maintainability / fault-tolerance test; it is a held trademark and the de facto global vocabulary. ANSI/TIA-942-C (revision C, May 2024) is a full-facility standard — telecom, architectural, electrical, mechanical — with its own Rated-1..4 scale (renamed from "Tier" to avoid confusion with Uptime). EN 50600 and its international twin ISO/IEC 22237 classify Availability Class 1–4 (and separate Protection Classes for physical security). The numerals loosely align — higher is more resilient — but the bodies explicitly disclaim equivalence, certify different scopes, and use different test methods. Use this table to translate intent; never to assert that a Tier III contractually is an Availability Class 3.
| Uptime Tier | TIA-942-C Rated | EN 50600 / ISO 22237 Availability Class | Redundancy posture | Concurrently maintainable? | Fault tolerant? | Conventional availability ref |
|---|---|---|---|---|---|---|
| Tier I — Basic Capacity | Rated-1 | Availability Class 1 (low) | N — single path, no redundancy | No | No | ~99.671% (~28.8 h/yr down) |
| Tier II — Redundant Capacity Components | Rated-2 | Availability Class 2 (extended) | N+1 components, single distribution path | No (single path) | No | ~99.741% (~22 h/yr) |
| Tier III — Concurrently Maintainable | Rated-3 | Availability Class 3 (high) | N+1, dual path (one active) | Yes | No | ~99.982% (~1.6 h/yr) |
| Tier IV — Fault Tolerant | Rated-4 | Availability Class 4 (very high / fault-tolerant) | 2N or 2(N+1), active-active | Yes | Yes (single-fault tolerant) | ~99.995% (~26 min/yr) |
2. ASHRAE thermal classes — air (A1–A4) and liquid (W17–W45+)
ASHRAE TC 9.9 (Thermal Guidelines for Data Processing Environments, 5th ed.) defines the supported environmental envelope. The legacy air classes A1–A4 set allowable inlet-air temperature and humidity; they describe a world at or below the air-cooling cliff (~41 kW/rack practical ceiling) and are increasingly a description of the past for dense AI halls. The 5th edition's liquid-cooling chapter introduced the W-classes, keyed to the maximum facility-supply-water temperature delivered to the rack/CDU; higher W-numbers mean warmer water, which unlocks more hours of free cooling and viable heat reuse, at the cost of a tighter thermal margin against the chip. The AI-relevant rows are the warm-water classes (W32/W40/W45), which is where GB200-class direct-to-chip designs and the forward 45 °C-coolant Vera Rubin roadmap sit.
| Air class | Typical equipment | Allowable dry-bulb (inlet) | AI-relevance |
|---|---|---|---|
| A1 | Enterprise servers, storage (tightest control) | 15–32 °C | Legacy / strict environments; rare in new AI halls |
| A2 | Volume servers / IT (common datacenter) | 10–35 °C | Baseline air-cooled IT; below the AI density wall |
| A3 | Wider-tolerance IT | 5–40 °C | Free-cooling-leaning air designs; pre-liquid |
| A4 | Widest-tolerance IT | 5–45 °C | Max economizer hours for air; still air-only |
| Liquid class | Max facility supply water | Heat-rejection implication | Heat-reuse potential | AI-relevance |
|---|---|---|---|---|
| W17 | ≤ 17 °C | Chiller typically required | Low | Conservative DLC; high chip margin, poor PUE/WUE |
| W27 | ≤ 27 °C | Economizer in cool climates; chiller assist | Low–moderate | Common transitional DLC operating point |
| W32 | ≤ 32 °C | Largely chiller-less in many climates | Moderate | Mainstream warm-water DLC target (GB200-class) |
| W40 | ≤ 40 °C | Dry-cooler / tower, broad free-cooling window | Good (district-heat viable) | Warm-water design point; strong PUE/WUE |
| W45 | ≤ 45 °C | Free cooling in nearly all climates | Strong (heat reuse practical) | Forward roadmap (Vera Rubin 45 °C coolant) |
3. ISO/IEC 30134 efficiency-KPI family
ISO/IEC 30134 is the standardized KPI series — the formal home of PUE and its successors. It matters because regulators and disclosure regimes increasingly cite the standard part rather than the vernacular metric, and because the post-PUE metrics (WUE, REF, ERF, CER) are exactly the ones AI density and water scrutiny have pushed to the front. Each metric is a separate numbered part; cite the part, not just the acronym, when a number lands in a sustainability filing. → the metric stack is engineered in Chapter 15.1.
| Part | KPI | What it measures | Direction | Why it matters for AI |
|---|---|---|---|---|
| 30134-2 | PUE — Power Usage Effectiveness | Total facility energy ÷ IT energy | Lower → 1.0 | Headline efficiency; liquid pushes toward ~1.1, but PUE hides chip-level waste |
| 30134-3 | REF — Renewable Energy Factor | Renewable energy ÷ total energy consumed | Higher → 1.0 | Clean-power procurement; pairs with 24/7 CFE claims |
| 30134-4 | ITEEsv — IT Equipment Energy Efficiency (servers) | Server work delivered per unit energy | Higher | Shifts the lens from facility to the accelerator doing the work |
| 30134-5 | ITEUsv — IT Equipment Utilization (servers) | Actual vs rated server utilization | Higher | Stranded-capacity detector; idle GPUs are the dominant waste |
| 30134-6 | ERF — Energy Reuse Factor | Reused energy ÷ total energy consumed | Higher | Quantifies heat reuse / district heating credit |
| 30134-7 | CER — Cooling Efficiency Ratio | Cooling capacity delivered per unit cooling energy | Higher | Isolates cooling-plant efficiency — the AI cost driver |
| 30134-8 | CUE — Carbon Usage Effectiveness | Carbon emissions ÷ IT energy | Lower | Carbon-weighted twin of PUE; disclosure-facing |
| 30134-9 | WUE — Water Usage Effectiveness | Water consumed ÷ IT energy (L/kWh) | Lower → 0 | Water scrutiny; evaporative vs closed-loop is now a siting gate |
4. The OCP spec library relevant to AI infrastructure
The Open Compute Project is where the open-hardware reference specs for AI-scale racks, power, and security live — and where the hyperscalers contribute the designs that OEMs then productize. These specs version quickly; the editions below are the 2025–2026 reference points. The AI-relevance column is the filter: the rows that matter for 132 kW-and-beyond racks are the rack/power and security families, not the legacy ORv2 baseline.
| Spec / project | Edition / status | What it standardizes | AI-relevance |
|---|---|---|---|
| Open Rack v3 (ORv3) | Released; the current baseline | 48 V busbar rack, power shelves, BBU trigger behavior, mechanical envelope | Baseline rack the dense-power specs extend; ~120 kW-class DLC racks build on it |
| Open Rack Wide (ORW) | Meta 2025 OCP design | Double-wide rack form factor for rack-scale GPU systems | Hosts 72-GPU double-wide systems (e.g. AMD Helios / MI355X–MI455X, UALink scale-up) |
| Mt Diablo / Diablo 400 (power base) | v0.5.2, 2025-05-30 (Google/Meta/Microsoft) | Disaggregated sidecar power; 48 V → ±400 VDC, 400/800 VDC transition for >150 kW racks | The path to >500 kW / ~1 MW Kyber-class racks; decouples power from the IT rack |
| NVIDIA GB200 NVL72 contributed designs | Contributed to OCP (2024–2025) | Rack/tray mechanical-electrical-thermal: ~120 kW DLC, 1,400 A busbar, blind-mate liquid manifold | Canonical reference for the 2026-default liquid-cooled training rack |
| OCP S.A.F.E. (Security Appraisal Framework & Enablement) | Active program (OCP + Microsoft) | Standardized third-party hardware/firmware security review via accredited Security Review Providers (SRPs) | One shared security audit accepted by many buyers; supply-chain-security backbone |
| Caliptra (silicon root of trust) | 2.1 (data-at-rest protection); IP shipping in chips from 2026 | Open-source silicon RoT subsystem for measured boot and attestation | Hardware root of trust for AI accelerators/servers; complements S.A.F.E. attestation |
Deep dive: how S.A.F.E. and Caliptra fit together
These two OCP security efforts are complementary, not redundant. Caliptra is a hardware artifact: an open-source silicon root-of-trust subsystem integrated into a chip, providing measured boot and the cryptographic measurements a device attests to. OCP S.A.F.E. is a process: a framework under which accredited third-party Security Review Providers audit the hardware design and firmware, producing a security review that multiple cloud buyers can accept through a single shared evaluation rather than each running their own. S.A.F.E. assessments provide assurance about the measurements that Caliptra attests — the audit validates that what the root of trust is measuring is trustworthy. Caliptra IP is being integrated across the ecosystem with silicon appearing from 2026 (Caliptra 2.1 adds data-at-rest protection); S.A.F.E. is the audit layer that lets the resulting attestations be trusted across the supply chain. → hardware root-of-trust and firmware security in Chapter 11.4; supply-chain provenance in Chapter 11.3.
5. Security & compliance frameworks
Which compliance regimes bind depends on who the tenants are and what data runs. A commercial neocloud lives on SOC 2 and ISO/IEC 27001; a US-government workload adds FedRAMP and, for defense contractors, CMMC; an operator that owns substation/transmission assets inherits NERC CIP as critical-infrastructure cyber regulation; and any operator productizing the AI itself increasingly faces ISO/IEC 42001, the first AI-management-system standard. These are not interchangeable — they differ in authority (voluntary attestation vs federal mandate), scope (the org vs the cloud offering vs the AI system vs the grid asset), and audit cadence. → compliance and certification governance in Chapter 11.11.
| Framework | Authority / type | Scope | Applies when | AI-DC note |
|---|---|---|---|---|
| SOC 2 (Type I / II) | AICPA — voluntary attestation | Org controls vs Trust Services Criteria (security, availability, etc.) | Commercial customers demand assurance | Table-stakes for any neocloud / colo selling to enterprises |
| ISO/IEC 27001 | ISO — certifiable mgmt system (ISMS) | Information-security management system, org-wide | Global / enterprise procurement | Broad baseline; a 20x Low pathway accepts it as evidence |
| ISO/IEC 42001 | ISO — certifiable mgmt system (AIMS) | Artificial-intelligence management system | Operator builds/operates/productizes the AI itself | First AI-MS standard (2023); governance for the model, not just the building |
| FedRAMP (Rev 5) | US GSA / FedRAMP PMO — federal authorization | Cloud service offering serving US-government data | Selling cloud to US federal agencies | Baseline-driven (Low/Mod/High); the legacy authorization path |
| FedRAMP 20x | US FedRAMP PMO — automation-based authorization | Same, via Key Security Indicators + machine-readable validation | New/continuous federal authorizations | Phase-1 pilot Apr–Sep 2025; 20x Low can leverage SOC 2 / ISO 27001 / CMMC L2 evidence |
| CMMC (2.0, Levels 1–3) | US DoD — mandatory for contractors | Protection of FCI / CUI in the defense supply chain | Handling DoD contract information | Level 2 maps to NIST SP 800-171; gates defense AI workloads |
| NERC CIP | NERC / FERC — mandatory reliability standards | Cyber security of the Bulk Electric System (BES) | Operator owns substation/transmission BES cyber assets | Triggered when an AI campus owns/operates grid assets behind the POI → Chapter 4.3 |