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 range," "an ORV3 rack," "SOC 2 Type II." This chapter admits 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, since it lets thousands of independent actors build to one interface without re-negotiating it. But the snapshot ages, and the rate it ages at is 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 and 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 eligible providers in Q3 2026, and ISO/IEC 42001 went from publication in 2023 to its first ANAB-accredited certification body in 2024. Pin a design to a fast-clock spec at the wrong version and you have committed to an interface the ecosystem has already left behind. This chapter is the map: what each standard decides for you, what it leaves open, and where version drift will bite. Begin an applicability record: jurisdiction, intended workload and tenant, enforcing authority or contract, document and edition, assessed boundary, proof 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 operating range 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 or 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, certify to the other and find 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 has re-versioned will find the power shelves orphaned a generation early. A sales team that promises FedRAMP before understanding 20x's automation model will quote a timeline 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 are 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 one ladder. They are not. They measure overlapping but distinct things, they certify different artifacts, and their numeric levels do not translate cleanly.

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 of 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. Third-party bodies certify it, and it spans cabling, architecture and mechanical/electrical alongside resilience, a broader and more prescriptive scope than Uptime's. EN 50600 / ISO/IEC 22237 is the international and European family, organized around Availability Classes 1–4 and separate Protection Classes; CENELEC publishes EN 50600 and ISO/IEC publishes 22237. They can be procurement requirements, while the EU reporting and sustainability scheme has its own legal basis in Appendix A. Before using any of them as a procurement gate, ask for the certificate or report, its exact scope and exclusions, and the design, construction or operating records it covers.

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 and humidity range 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 range. Use only the class your chosen equipment supports.

The liquid classes are the W family, keyed to facility-water supply capability (W17, W27, W32, W40, W45 and the open-ended W+). They are inputs to a liquid-system design. They do not select the 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 once your rack's TCS limits, CDU approach, coolant, flow, pressure, climate and rejection plant all work at that point. 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. It includes PUE (30134-2), REF renewable energy factor (30134-3), ITEEsv and ITEUsv server efficiency and utilization, and CUE carbon usage effectiveness, plus the water and cooling-effectiveness metrics that EN 50600 folds in. This matters beyond engineering because the definitions become load-bearing in contracts: colo leases with PUE pass-throughs, green-bond covenants, EU 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 keeping the edition the applicable contract or reporting rule requires. The ASHRAE–PNNL–NEMA AI Data Center Energy Performance Framework adds 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 limits in Chapter 5.1.

The Open Compute Project is the fast clock incarnate. Of the standards families, open hardware saw the most movement in 2025–2026. OCP specs are vendor-consortium standards, published, implementable and second-sourceable, and they re-version between summits. They force the deepest decision in this chapter: build to open hardware or to a vendor's integrated reference design. Open hardware buys second-source optionality, serviceability on common parts and freedom from a single supplier's roadmap. An integrated vendor design buys 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), and the OU geometry that hyperscaler AI racks build on. Meta's Catalina and others extend this substrate.
• 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, and a shared rack lineage does not mean every OEM implementation is qualified.
• 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). It pushes rack power delivery from 48 V to ±400 VDC or 800 VDC and enables 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 founded by AMD, Google, Microsoft and NVIDIA, with its implementation hosted by CHIPS Alliance and its specification through OCP: 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 a 100 kW+ hall to a pre-ORW or pre-Diablo power architecture 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. Settle early which regimes your target tenants and their workloads require, because the most expensive controls and 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, so you cannot "buy it late" because the observation window has to elapse. ISO/IEC 27001 is the international information-security management system standard, the global passport that SOC 2's US-centric report is not. ISO/IEC 42001 is the new one to watch: the first AI management-system standard (published December 2023). The first ANAB-accredited certification body followed in September 2024, and major vendors (e.g. SAP) now certify. 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), and its current certification class and rules, not 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 eligible providers as of 2026-09-04, with a Class D pilot planned for Phase 4 (FY27).

CMMC (Cybersecurity Maturity Model Certification) gates defense-industrial-base procurement involving FCI or CUI. Level 1 assesses FAR 52.204-21 safeguards, Level 2 assesses NIST SP 800-171 Rev 2 requirements, and Level 3 adds a subset of NIST SP 800-172 requirements. Its enforcement clock slipped. As of 2026-10-05, the Department of War's 2026-07-13 suspension pauses the Phase II requirement for Level 2 C3PAO certification as a condition of award, scheduled for 2026-11-10, and the later rollout milestones, pending a reform review. Applicable Phase I self-assessment and affirmation requirements remain in force, and voluntary Level 2 C3PAO certification assessments remain available. And the NIST families (the SP 800 series, the Cybersecurity Framework, plus the firmware and 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) combine open hardware, vendor integration and cloud-service boundaries differently.

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 and the campus, rather than one supplier's product names. A "SuperPOD SU," 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 profile that you stamp out N times to fill a hall. Mapping a vendor RA onto that vocabulary lets you compare candidate blocks across suppliers and reason about the facility independently of which accelerator wins this generation. Second-sourcing still requires software, mechanical, electrical, cooling, fabric and support testing. → 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 formal standard or fast consortium or 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 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 can strand capital already committed to facility plant and interfaces: freezing a hall to a power spec that re-versions, or quoting a compliance timeline that a regime transition obsoletes. Record the applicable edition and reopening event for both clocks. Close the intake with an owner and a proof 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.