The Standards & Specifications Landscape (Living Index)

Every other chapter in this guide cites standards as if they were bedrock — "design to Tier III," "the ASHRAE A2 envelope," "an ORV3 rack," "SOC 2 Type II." This chapter is where we admit the bedrock moves. A standard is a frozen consensus: a snapshot of what a committee, a vendor consortium, or a regulator agreed was "good enough" on a particular date. The freezing is the point — it lets thousands of independent actors build to the same interface without re-negotiating it. But the snapshot ages, and the rate at which it ages is itself a design input you must price.

The defining tension of the 2026 standards landscape is that the clock split. The resilience, thermal, and physical-security standards still move on the slow clock — multi-year revision cycles, formal balloting, national-body adoption. The open-hardware, AI-governance, and federal-compliance standards moved onto a fast clock — OCP specs re-version between annual summits, FedRAMP 20x ran two pilot phases before opening to all qualifying providers in Q3 2026, ISO/IEC 42001 went from 2023 publication to accredited certification bodies operating through 2025–2026. Pin a design to a fast-clock spec at the wrong version and you have committed to an interface that the rest of the ecosystem has already left behind. This chapter is the map: what each standard decides for you, what it leaves open, and where the version drift will bite. Begin an applicability record: jurisdiction, intended workload and tenant, enforcing authority or contract, named document and edition, assessed boundary, evidence owner and due date. The maintained document index is Appendix A.

The standards that govern an AI data center fall into four families, and sorting them by family and by clock-speed is the first move. Facility resilience (Uptime, TIA-942, EN 50600 / ISO 22237) answers "how many ways can this building fail, and does it keep running through maintenance and faults." Thermal and efficiency (ASHRAE TC 9.9, ISO/IEC 30134) answers "what envelope may the equipment live in, and how do we measure how well we run it." Open hardware (OCP) answers "what does a rack, a power shelf, a root-of-trust actually look like, and can I second-source it." Security and compliance (SOC 2, ISO 27001/42001, FedRAMP, CMMC, NIST) answers "may I host this tenant, this workload, these weights, in this jurisdiction."

Mis-sorting costs real money. A buyer who treats Uptime Tier and TIA-942 Rated as interchangeable will commission to one and certify to the other and discover the gap at audit. A designer who pins a hall to an ASHRAE air class when the workload demands a liquid W-class has scoped the wrong building. An operator who builds to an OCP spec that re-versioned will find their power shelves orphaned a generation early. And a sales team that promises FedRAMP before understanding 20x's automation model will quote a timeline that the new regime makes obsolete. The rest of this chapter takes each family in turn. A law, adopted code, customer clause, certification scheme and voluntary reference architecture get separate authority entries; sharing a technical topic does not give them the same force.

Three resilience frameworks dominate, and the most common error in the industry is treating them as a single ladder. They are not. They measure overlapping but distinct things, they certify different artifacts, and their numeric levels do not cleanly translate.

Uptime Institute Tier I–IV is a topology-and-operations classification, certified by Uptime itself in three flavors: Tier Certification of Design Documents (the drawings), of the Constructed Facility (the as-built), and Operational Sustainability (how it is run). Its conceptual core is the pair concurrent maintainability (Tier III — any component can be taken offline for service without dropping load) and fault tolerance (Tier IV — any single unplanned failure is survived). Uptime classification defines topology and operational outcomes, not a facility-availability SLA. TIA-942-C (the May 2024 revision) is a full-facility telecommunications-infrastructure standard with a parallel Rated 1–4 resilience scheme, but it is certified by third-party bodies and spans cabling, architecture, and mechanical/electrical alongside resilience — a broader, more prescriptive scope than Uptime's. EN 50600 / ISO/IEC 22237 is the international/European family, organized around Availability Classes 1–4 and separate Protection Classes, with CENELEC publishing EN 50600 and ISO/IEC publishing 22237. They can be procurement requirements; the EU reporting and sustainability scheme has its own legal basis in Appendix A. Ask for the certificate or report, its exact scope and exclusions, and the design, construction or operating evidence it covers before using it as a procurement gate.

Two standard families set the thermal design basis and the efficiency scorecard, and in the AI era they are where the slow clock is being forced to move fastest. ASHRAE TC 9.9 publishes the Thermal Guidelines for Data Processing Environments, 5th ed. (2021; revised and expanded 2022), alongside the separate 2024 Technical Bulletin Liquid Cooling: Resiliency Guidance for Cold Plate Deployments. Its air classes A1–A4 and H1 define the temperature/humidity envelope air-cooled equipment may operate in. Within A1–A4, wider supported temperature envelopes can buy economizer hours at the cost of thermal and reliability margin; H1 covers high-density air-cooled equipment with a tighter inlet envelope. Use only the selected equipment’s supported class. Its liquid classes—the W family, keyed to facility-water supply capability (W17, W27, W32, W40, W45, and the open-ended W+)—are inputs to a liquid-system design; they do not select cooling modality or prescribe a TCS operating temperature, delta-T, or flow. A warmer qualified FWS operating point can increase economizer and heat-reuse opportunity, but only after the named rack's TCS limits, CDU approach, coolant, flow, pressure, climate, and rejection plant close. A W32-capable facility therefore differs materially from a W17-capable one, but the class alone is not the rack operating point.

ISO/IEC 30134 is the KPI family — the standardized, auditable definitions of the efficiency metrics the whole industry quotes: PUE (30134-2), REF renewable energy factor (30134-3), ITEEsv and ITEUsv server efficiency/utilization, CUE carbon usage effectiveness, and the water and cooling-effectiveness metrics that EN 50600 folds in. The reason this matters beyond engineering: these definitions end up load-bearing in contracts — colo leases with PUE pass-throughs, green-bond covenants, the EU's Energy Efficiency Directive reporting, and the EU DC sustainability rating scheme. A metric you report casually in an engineering review becomes a number you are legally on the hook for. Pin ISO/IEC 30134-2:2026 for the current PUE definition, while retaining the edition required by the applicable contract or reporting rule. The ASHRAE–PNNL–NEMA AI Data Center Energy Performance Framework supplies lifecycle guidance alongside those requirements; Appendix A owns its release identity. → canonical definitions and the post-PUE metric stack in Chapter 15.1; thermal physics and the cooling-selection envelope in Chapter 5.1.

The Open Compute Project is the fast clock incarnate, and it is the standards family where 2025–2026 saw the most movement. OCP specs are vendor-consortium standards — published, implementable, second-sourceable — and they re-version between summits. The decision they force is the deepest in this chapter: build to open hardware or to a vendor's integrated reference design. Open hardware buys you second-source optionality, serviceability on common parts, and freedom from a single supplier's roadmap; an integrated vendor design buys you validated performance and a single throat to choke, at the cost of lock-in. The names you must know:

• Open Rack v3 (ORV3) — the 21-inch open-rack baseline: 48 V busbar, standardized power shelves and battery-backup units (BBUs), the OU geometry that hyperscaler AI racks build on. This is the substrate Meta's Catalina and others extend.
• Open Rack Wide (ORW) gives rack-scale systems more width for power, cooling and service access. Select its base specification and Meta Design specification separately; the preliminary canister guide has a different status. Appendix A identifies the documents; a shared rack lineage does not qualify every OEM implementation.
• Mt. Diablo / Diablo 400 — the disaggregated sidecar power rack co-authored by Google, Meta, and Microsoft (Diablo 400 spec at v0.7.0 as of March 2026 — it was v0.5.2 only ten months earlier, the fast clock in action), pushing rack power delivery from 48 V to ±400 VDC or 800 VDC and enabling IT racks from ~100 kW up to ~1 MW. This is the open analog of the 800 VDC transition NVIDIA is driving for Kyber-class racks.
• S.A.F.E. (Security Appraisal Framework and Enablement) — OCP's independent firmware-security audit framework: accredited Security Review Providers (SRPs) audit device firmware against a checklist and publish CVSS-scored findings, with RIM/SBOM and Caliptra integration.
• Caliptra — the open silicon root-of-trust (Microsoft / Google / OCP / CHIPS Alliance): a DICE-based identity and measured-boot block integrated into the SoC, separating the hardware RoT from the BMC. The open counterweight to proprietary RoT.

OCP also launched its cross-cutting Open Data Center for AI initiative to standardize rack, power, and telemetry interfaces across these pieces. The version-drift risk here is real: an operator who built to a pre-ORW or pre-Diablo power architecture for a 100 kW+ hall is now a generation behind the open ecosystem. → power architecture in Chapter 4.1 and the 800 VDC transition in the electrical part; rack integration in Chapter 7.13; the security specs (Caliptra, S.A.F.E.) in Chapter 11.3 and Chapter 11.4.

The compliance family is where the standards landscape touches revenue most directly: a missing certification does not make your facility worse, it makes whole categories of tenant unable to sign. Which regimes your target tenants and their workloads require is the question to settle early, because the most expensive controls and the longest audit lead times tend to be the ones discovered after design freeze.

SOC 2 (AICPA) is the commercial baseline — a Type II report attesting that controls operated effectively over the agreed reporting period, which means you cannot "buy it late": the observation window has to elapse. ISO/IEC 27001 is the international information-security management system standard, the global passport SOC 2's US-centric report is not. ISO/IEC 42001 is the new one and the one to watch: the first AI management-system standard (published 2023), with accredited certification bodies operationalized through 2025–2026 and major vendors (e.g. SAP) certifying — it is becoming the AI-governance analog of 27001, and tenants building regulated AI products will increasingly ask for it. FedRAMP gates US federal cloud workloads, and it is mid-transition: FedRAMP 20x uses outcome-focused assessment and automatable Key Security Indicators (KSIs); its current certification class and rules, rather than a historical control-count comparison, govern admission; Phase 1 piloted Apr–Sep 2025, Phase 2 ran Nov 2025–Mar 2026, and Phase 3 is active — Classes A, B and C are all open to qualifying providers as of 2026-09-04, with a Class D pilot planned for Phase 4 (FY27). CMMC (Cybersecurity Maturity Model Certification) gates US defense-industrial-base data, with its tiered levels mapping onto NIST SP 800-171 — but its enforcement clock slipped: the Department of War suspended Phase II third-party (C3PAO) assessments on 2026-07-13, pausing the 2026-11-10 condition-of-award step pending a reform review, while Phase I self-assessment obligations remain in force. And the NIST families (the SP 800 series, the Cybersecurity Framework, plus the firmware/supply-chain documents SP 800-193 and SP 1800-34) are the substrate the others are built on.

The last family is not a standard at all, but it behaves like one: vendor reference architectures. NVIDIA's DGX SuperPOD (the canonical scalable-unit blueprint, with generation-specific SU sizes — up to 32 H100 systems, 8 GB300 rack systems, or 72 Rubin NVL8 systems in the cited reference architectures), MGX (the modular rack/server spec OEMs build to), and DSX (the gigawatt-scale "AI factory" reference design with a digital-twin blueprint) are de facto standards because so much of the ecosystem builds to them. Other deployment references — Meta’s Catalina, AMD’s Helios, Google’s TPU/OCS pods, AWS’s Trainium UltraClusters — expose different combinations of open hardware, vendor integration and cloud-service boundaries.

This guide reads every reference architecture through a vendor-neutral capacity-unit vocabulary — the rack, the scale-up (NVLink/UALink) domain, the scalable unit (SU), the pod, the campus — rather than memorizing one supplier's product names. A "SuperPOD SU" and a "Helios pod" and a "TPU slice" are all instances of the same abstraction: a repeatable capacity block with a defined power, cooling, and fabric envelope that you stamp out N times to fill a hall. When you map a vendor RA onto that vocabulary, you can compare candidate blocks across suppliers; second-sourcing still requires software, mechanical, electrical, cooling, fabric and support qualification, and you can reason about the facility independently of which accelerator wins this generation. → the capacity-unit vocabulary is defined in Chapter 0.3; the per-archetype requirements matrix and reference SUs are built out in Chapter 1.7; the rack-to-pod-to-cluster integration is engineered across Part 7, beginning at Chapter 7.1.

A common row format exposes the interfaces that differ. It does not make a TPU slice, a Helios rack and a SuperPOD scalable unit interchangeable. The buyer chooses a supported procurement boundary, then assigns software migration, facility interfaces and integration acceptance before ordering.

When a standard appears anywhere in this guide — and they appear constantly — ask four questions of it. Which family (resilience, thermal/efficiency, open hardware, security/compliance), because that tells you what it decides and what it leaves open. Which clock (slow-moving formal standard or fast-moving consortium/regulator spec), because that tells you how soon it drifts. Which artifact does it certify (a design, a built facility, an operation, a control window), because two facilities "compliant with X" can have certified wildly different things. And which version, as of when, because the version is a timestamp and the right design tolerates the drift on the fast-clock specs while leaning on the stability of the slow-clock ones.

The cost of getting this wrong is asymmetric. Under-specifying a slow-clock standard (commissioning to Rated 2 when the workload needed Rated 3) is a known, bounded, design-time error. Over-trusting a fast-clock standard — freezing a hall to a power spec that re-versions, or quoting a compliance timeline that a regime transition obsoletes — is the one that strands capital, because by the time it bites, the concrete is poured. Record the applicable edition and reopening event for both clocks. Close the intake with an owner and evidence due date for each binding requirement; a missing artifact is a HOLD on the affected commitment, not a reason to duplicate every standard in the design basis.