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. Start an applicability record for each requirement: jurisdiction, intended workload and tenant, who enforces it (authority or contract), document and edition, the boundary it covers, the owner of the proof and the date it is due. 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. Keep the authority behind each requirement separate as well: a law, an adopted code, a customer clause, a certification scheme and a voluntary reference architecture can cover the same topic without carrying 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. Either can be written into a procurement requirement; EU energy reporting and the EU's data-center sustainability rating scheme rest on their own legal basis, listed 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 ranges 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 the temperature, delta-T or flow of the technical cooling system (TCS) that feeds the racks. A warmer facility-water supply (FWS) can add economizer hours and heat-reuse value, but only when your rack's TCS limits, CDU approach, coolant, flow, pressure, climate and rejection plant all work at that temperature. 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 (June 2026) adds lifecycle design and operating guidance alongside those requirements; it is guidance, not a mandatory standard, and Appendix A lists its release details. → 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 (formerly Diablo 400) — the disaggregated sidecar power rack co-authored by Google, Meta and Microsoft. Its spec reached a final 1.0.0 on October 8, 2026, after v0.5.2 in May 2025 and v0.7.0 in March 2026: the fast clock in action. It pushes rack power delivery from 48 V to what 1.0.0 calls differential 800 VDC (+400 and −400 VDC around a midpoint), and one power rack is rated from 800 kW to beyond 1 MW, with racks paralleled for more. It is the open counterpart to NVIDIA's 800 VDC architecture for Kyber-class racks, though NVIDIA's design is separate and unipolar (Chapter 4.7).
• S.A.F.E. (Security Appraisal Framework and Enablement) — OCP's independent firmware-security audit framework: OCP-approved Security Review Providers (SRPs) audit device firmware against a checklist and publish CVSS-scored findings, with RIM/SBOM and Caliptra integration. A review endorses one product at one firmware hash, at a stated scope; it does not certify the vendor.
• 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; its design-principles specification reached revision 0.7.0 (effective 2026-08-27; AMD, Google, Meta and NVIDIA), and its facility targets for 2027–2028 hardware are set out in Chapter 6.1. Two newer documents belong on the same watchlist. OCP's grid-resilience specification v1.0.0 (Google, Meta, Microsoft and NVIDIA; effective 2026-09-17) sets how long computing load must stay connected through a voltage sag before it may transfer to backup; it is an industry specification, not a regulation (Chapter 13.6). The Open Switch Platform Architecture (OSPA) has a revision 1.0.0 candidate under review (October 2026). OCP has started an Energy Project, announced in its October 2026 summit review, to develop requirements and reference architectures for on-site generation and energy storage. It has published no specification yet; its storage-requirements white paper is covered in Chapter 4.5. 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; 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); admission depends on the certification class and its current rules. 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). On 2026-10-08 FedRAMP announced that it will stop accepting new Rev5 certifications on 2027-06-11, and it has committed to publish a transition path for existing Rev5 offerings by the end of Phase 5 (estimated FY27). The cutoff matters most to a provider with little Rev5 progress and no committed agency sponsor, which should start on 20x instead.

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. On 2026-07-13 the Department of War suspended Phase II, which would have made Level 2 C3PAO certification a condition of award from 2026-11-10, along with the later rollout milestones. A companion memo from the Under Secretary of War for Acquisition and Sustainment, implementing the Chief Information Officer's suspension, directed contracting officers to strip Phase II and III requirements out of existing contracts by modification, made before the contract's next option period or folded into its next scheduled administrative modification. DFARS Class Deviation 2026-O0025 carries that direction, currently as Revision 3 of 3 September 2026 (Chapter 11.11). A reform task force ran a 60-day review, and as of mid-October 2026 its recommendations had not been published. Phase I self-assessment and annual affirmation remain in force, and voluntary Level 2 C3PAO 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. Benchmarks move on the same fast clock: MLPerf Inference v6.1 (2026-09-16) added end-to-end RAG and edge agentic tests, MLPerf Storage v3.0 changed its validity thresholds, and MLPerf Training adds a post-training benchmark from v6.1.

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. Give each binding requirement an owner and a date by which its proof is due. If a certificate, report or record is missing, the commitment it supports waits; that gap does not justify copying every standard into the design basis.