Public review edition · Validation Candidate for Independent Review · Release AIDCF-REL-2026.10.1, 2026-10-10

Can your AI infrastructure support the outcomes your AI services depend on?

The AI Data Centre Facilities Assurance Framework (AIDCF) is an open, evidence-driven assessment methodology. It connects facilities, power, cooling, compute, storage, networks, operations and suppliers to the requirements of a defined AI service, and brings existing engineering and security evidence into one traceable argument, so that dependencies, safeguards, gaps and uncertainty are visible before an accountable person decides.

See how it works See the synthetic example View on GitHub

Research-stage methodology · Not a certification · No completed real-world assessment recorded · Independent validation pending

Synthetic example One failure, traced from the water supply to the decision: FS-04 Heatwave and chiller trip

01 Failure
Heatwave above design ambient. The cooling chain loses capacity.
1. External supplyMake-up water supply
2. Facility engineeringFacility water systemUNKNOWN U-003
3. Facility engineeringChiller
4. Facility engineeringCDU 2
5. Facility engineeringLiquid-cooling secondary loop
02 Impact
Accelerators lose cooling, so inference latency breaches its tolerance.
1. AI technology chainAccelerator compute cluster
2. AI service functionProvide accelerator compute
3. Service outcomeInference latency
Ends DEGRADED
03 Evidence
The safeguards that should contain it are not shown to work.
- Leak detection and isolationTHM-019 Leak Detection Not assessedOPS-013 Alarm Rationalisation Partial
- Accelerator thermal throttlingCMP-019 Error and Degradation Detection Not assessed
- Exclusivity of the facility water plantUNKNOWN U-003, severity US5
04 Decision
Not assured
Alarm Rationalisation is a critical input to CG-07 Critical control-system integrity. A partial result fails the gate, and a failed gate caps the decision however good the rest is.

Follow this failure step by stepDrawn from the AIDCF-015 synthetic dataset. It describes no real facility.

The problem

A reliable AI service needs dense, transient power, liquid cooling, tightly coupled fabrics, checkpoint storage, building control systems and outside suppliers to work together. Existing reviews cover these to different extents. Some, such as integrated systems testing, reliability studies and OT risk assessments, cross several domains. Whether a given set of reviews, as scoped for a particular site, shows that the AI workload itself can deliver its outcomes is an open question that depends on that scope.

Common review types and the gap each leaves for an AI workload
Review commonly used today	What it establishes	What it may leave open for an AI workload, depending on scope
Tier certification, ANSI/TIA-942 rating, EN 50600 / ISO/IEC 22237 classification	Facility design topology and availability class	Whether a training or inference service survives the failures that matter to it, such as loss of a cooling loop at full accelerator load, a fabric partition or a checkpoint-store outage
Commissioning and integrated systems testing	That systems, often several of them together, worked as designed at handover	Behaviour after later changes, under real AI load profiles and through recovery, unless these were in the test scope
Engineering and reliability studies (power system studies, FMEA, fault tree analysis)	Failure modes and fault behaviour of the systems studied, which can cross power, cooling and controls	Whether the study follows each failure through to the AI service outcomes, and whether it still holds after changes
OT security risk assessment (IEC 62443-3-2)	Zones, conduits, threats and target security levels for the control systems in scope	How a compromise would affect power, cooling and the AI workload, where that consequence is outside the assessment scope
ISO/IEC 27001, SOC 2 and similar reports	That a security management system and selected controls are in place for the declared scope, which can include building and OT control systems	Whether that scope actually reaches the power and cooling control systems, and how a failure there would affect AI outcomes
ISO/IEC 42001, NIST AI RMF	Governance of AI systems and their risks	The physical and technical infrastructure those AI systems depend on
Technical due diligence	A point-in-time expert opinion	A reproducible, evidence-linked argument that a second assessor could re-perform

The project’s own analysis, not a survey or a measured result. A particular review may cover more than shown here. AIDCF treats existing certifications and reports as bounded evidence, not as proof that an AI capability is resilient.

The question AIDCF answers

Can this specific AI capability, under these operating conditions, deliver its required outcomes, and what is the evidence?

What AIDCF is

AIDCF evaluates whether the infrastructure behind a defined AI capability can meet that capability’s required outcomes under stated conditions. It builds a traceable argument from dependencies and failure scenarios, through safeguards, controls and evidence, to an accountable assurance decision. It complements existing technical standards and professional judgement; it does not replace them.

What AIDCF is not

Not a monitoring platform, an uptime guarantee, a data-centre certification, an AI model-safety framework, or a replacement for engineering assurance.

How AIDCF reasons

One chain runs from the decision being made to the decision taken. Every link must be supported, and every gap is recorded rather than assumed away.

1. Decision Question. What decision will rely on this assessment, and who will make it? (AIDCF-011)
1. Capability Instance. Which bounded deployment is the subject? (AIDCF-003)
1. Service Outcome. What must it achieve, within which tolerances? (AIDCF-003)
2. Required Function. Which functions must be delivered for each outcome? (AIDCF-003)
1. Architecture. Which systems, assets and interfaces implement each function, as built? (AIDCF-003, AIDCF-013)
1. Dependency and Fault Domain. What does each element rely on, and what fails together? (AIDCF-003)
1. Threat / Hazard / Failure Scenario. How can the outcome be defeated? (AIDCF-004)
2. Safeguard. Which real measures prevent, detect, contain or recover? (AIDCF-004)
1. Control. Which AIDCF requirements test those safeguards? (AIDCF-007A)
2. Evidence Requirement. What evidence would demonstrate each control at the required claim type? (AIDCF-008)
3. Evidence Object. What evidence was actually obtained? (AIDCF-008)
1. Control Assessment. What result does the evidence support, for which claim type and scope? (AIDCF-009)
2. Finding / UNKNOWN Record. What deficiencies and unresolved uncertainties remain? (AIDCF-008, AIDCF-009)
1. Gate Result. Are the non-compensating prerequisites met? (AIDCF-010)
1. Score Snapshot and Decision Recommendation. What do the results summarise to, and what does the engine recommend? (AIDCF-010)
2. Assurance Decision. What has accountable authority decided, with which conditions and validity? (AIDCF-010, AIDCF-011)

Simplified view. The canonical chain has 16 steps and is authoritative in AIDCF-002 Core Conceptual Model. Report and Reassessment Trigger: How is the decision communicated, and what invalidates it? It is built forwards to discover what matters and audited backwards to check that every part of the decision is supported.

Why AIDCF, alongside existing reviews

The proposed contribution is not that existing engineering assurance is deficient. It is that a set of individually credible assessments does not by itself give one traceable conclusion for a particular AI service. AIDCF organises the assurance argument at that level.

Illustrative example, not an empirical finding about existing reviews

A facility looks well assessed. Is the AI service assured?

Evidence available: power redundancy reviewed, cooling commissioned, protection coordination studied, OT security assessed.

Question still open: will the AI workload meet its recovery and service tolerances during a shared cooling-control failure?

Define the capability, service outcome and tolerance.
Trace the infrastructure, dependencies and failure paths that matter to it.
Evaluate the safeguards, controls and supporting evidence.
Decide whether the evidence supports a bounded assurance conclusion.

Specialist review and AIDCF compared by dimension
Dimension	Specialist review	AIDCF’s proposed role
Primary subject	A defined facility, system, process or engineering scope	A defined AI capability and its required service outcomes
Technical depth	Deep expertise within the engagement's scope	Uses specialist assessments as evidence and does not replace them
Failure analysis	FMEA, fault tree analysis and integrated systems testing can already analyse cross-system failures	Relates those failure paths to a capability-level assurance question
Evidence	What the relevant standard or engagement requires	Links each piece of evidence to the controls, gates and conclusion it supports
Uncertainty	Can be managed explicitly, depending on the method	UNKNOWN is a formal, visible state that caps the decision
Output	Certificate, test report, risk findings or engineering recommendation	A bounded, capability-specific assurance decision with an accountable owner
Validation maturity	Varies by standard and practice	Research stage: a validation candidate, not yet used on a real facility

Three hypotheses, not yet tested

AIDCF may improve traceability across assurance evidence.
It may expose gaps between component-level findings and service-level decisions.
It may make uncertainty and decision responsibility more explicit.

Untested claim. Whether AIDCF finds weaknesses that these reviews miss has not been tested. The draft comparative protocol (AIDCF-VAL-001 v1.1, section 10A) is designed to test it against engineering studies, commissioning and OT risk assessment. No comparative coding has started, so there are no results.

What it does differently

Claims are scoped to a capability

The subject is a bounded AI capability and its service outcomes, for example a training cluster that must complete jobs within a stated tolerance. A site-wide badge says nothing about that.

Critical gates do not average

15 critical gates are evaluated separately. A failed gate caps the decision however good the average score is, and a PARTIAL control result never lets a gate pass.

UNKNOWN stays visible

Missing or inadequate evidence is recorded as an explicit UNKNOWN with a severity. It caps the decision until it is resolved, instead of being quietly assumed fine.

Decisions are bounded and owned

The outcome is one of five decision states with stated conditions, limitations and a validity period, approved by an accountable person. It is not a certificate.

The five decision states, from strongest to most restrictive

REASONABLY_ASSUREDSufficient appropriate evidence supports the bounded top claim; all applicable gates PASS or APPROVED_NA; no undisposed US3 or higher UNKNOWN.
CONDITIONALLY_ASSUREDBounded top claim supported subject to named, owned, time-bound conditions; no gate FAIL or UNKNOWN.
LIMITEDSome sub-claims supported; material limitations, a gate UNKNOWN, or a gate FAIL whose AIDCF-010 ceiling is LIMITED prevent a broader conclusion.
INCONCLUSIVEEvidence, method, boundary or definition cannot support any determination.
NOT_ASSUREDEvidence demonstrates that the top claim, or a controlling gate, is not met.

Who it is for

Engineering and assurance practitioners apply AIDCF. Service owners and accountable executives use its outputs. It suits organisations that control, operate or can obtain meaningful evidence about the infrastructure behind an AI capability; it is not aimed at every tenant, IT team or AI model developer.

Data-centre owners and operators

Facilities directors, critical environment teams, reliability engineers, infrastructure operations leaders

Relate facility engineering evidence to the dependencies and service outcomes of a defined AI capability, and see where more testing or evidence may be needed.

AI infrastructure and service owners

GPU cluster and HPC platform owners, AI service engineering and workload reliability teams

See which facilities, systems, operating states and shared dependencies could stop the AI service meeting its objectives.

Assurance and engineering assessors

Commissioning specialists, OT assessors, engineering consultants, internal audit and technology risk teams

Use one structure to bring findings together, challenge unsupported conclusions and record what remains unknown, without displacing specialist assessments.

Decision owners

CTOs, infrastructure executives, service owners, investment and operational-risk committees

Receive a traceable statement of what is assured, under which assumptions, for how long, and what limits the decision.

Intended uses. Whether AIDCF delivers them in practice is what the validation programme is designed to test.

How an assessment works

AIDCF-009 Part A describes an eight-phase assessment lifecycle governed by stage gates SG0 to SG7, with defined review and approval responsibilities. Reassessment is triggered by relevant changes or events. An assessment can be run first-party, co-sourced, second-party or by an independent third party. Its length depends on scope and evidence access; no typical duration is claimed.

Initiate SG0 AuthoriseCharter the decision question, sponsor, decision authority and intended users.
Profile, scope and tailor SG1 ScopeDefine the capability, its boundary and dependencies, and which controls apply.
Plan SG2 PlanPlan the work, rules of engagement, safety approvals, evidence requests and team competence.
Collect and validate SG3 FieldworkDocument and configuration review, interviews, inspection, sampling, data analysis and testing.
Assess, analyse, gate and find SG4 Technical reviewControl results, failure scenarios, critical gate results, findings and UNKNOWNs.
Review SG5 Independent reviewAn independent reviewer challenges the evidence, gate logic and recommendation.
Decide and report SG6 Decide, SG7 ArchiveThe decision authority issues a bounded decision, or records a decision not to issue one.
Reassess Re-entry at SG0 or SG1Changes, incidents, evidence expiry and gate result changes trigger a delta or full reassessment.

What it is designed to produce

Practical problems and the AIDCF output designed for each
Practical problem	Intended output	Workpapers
Nobody has defined what must be assured for this AI capability	A bounded decision question and service-outcome requirements	WP-01 Assessment Charter, WP-02 Capability Profile
Infrastructure dependencies are spread across teams	A traceable capability and dependency model	WP-03 Scope and Boundary
Engineering and security findings use different scopes and evidence	Mapped controls, safeguards and evidence requirements	WP-04 Applicability Matrix, WP-06 Evidence Request, WP-12 Control Result
Important controls or dependencies cannot be verified	Explicit findings, UNKNOWN records and gate limitations	WP-13 to WP-17
Decision-makers receive reports without a consolidated assurance basis	An independently reviewed, bounded decision record	WP-18 Independent Review, WP-19 Assurance Decision

Roles include a sponsor, lead assessor, domain specialists, an evidence lead, technical and independent reviewers, a safety authority, the capability owner and the decision authority, with separation rules between them. Source: AIDCF-009 Part A practitioner handbook (draft for controlled review). These outputs are what the method is designed to produce, not demonstrated benefits such as fewer outages or lower assessment cost.

Worked example: a synthetic case

The reference implementation assesses one synthetic AI training and inference capability. It does not produce a favourable answer from thin evidence.

Computed decision

NOT_ASSURED

Controlled by CG-07 FAIL (failCeiling NOT_ASSURED), Critical control-system integrity.

3gates fail (CG-03, CG-07, CG-15)

5gates UNKNOWN

3.06%coverage (11 of 360 controls scored)

WITHHELDscore band

Trace the failures and the evidence

Fifteen assurance domains

Domains organise the assessment work and give every concern an owner. They do not partition the argument: a single failure scenario routinely crosses power, cooling, compute, storage, network, operations and security.

15assurance domains

90control families

360controls

15non-compensating critical gates

GOV controlsGovernance, Accountability and Assurance Direction6 families · 24 controls · gates CG-13Domain guide for Governance, Accountability and Assurance Direction
CAP controlsAI Capability, Service Outcome and Demand Management6 families · 24 controls · gates CG-01, CG-02, CG-13, CG-14Domain guide for AI Capability, Service Outcome and Demand Management
DEP controlsDependency, Concentration and External Reliance Management6 families · 24 controls · gates CG-02, CG-03, CG-13Domain guide for Dependency, Concentration and External Reliance Management
PHY controlsPhysical Site, Building and Security Infrastructure6 families · 24 controls · gates CG-04, CG-09Domain guide for Physical Site, Building and Security Infrastructure
POW controlsElectrical Power Infrastructure and Energy Continuity6 families · 24 controls · gates CG-04, CG-05, CG-07, CG-09, CG-10Domain guide for Electrical Power Infrastructure and Energy Continuity
THM controlsCooling, Thermal and Fluid Infrastructure6 families · 24 controls · gates CG-04, CG-06, CG-07, CG-09, CG-10Domain guide for Cooling, Thermal and Fluid Infrastructure
ENV controlsEnvironmental and Resource Performance6 families · 24 controls · gates CG-04Domain guide for Environmental and Resource Performance
CMP controlsAI Compute Infrastructure6 families · 24 controls · gates CG-08, CG-09, CG-10, CG-14Domain guide for AI Compute Infrastructure
STO controlsAI Storage and Data Infrastructure6 families · 24 controls · gates CG-08, CG-09, CG-10Domain guide for AI Storage and Data Infrastructure
NET controlsAI Network and Interconnect Architecture6 families · 24 controls · gates CG-08, CG-09, CG-10, CG-14Domain guide for AI Network and Interconnect Architecture
OPS controlsBuilding Operations and Service Management6 families · 24 controls · gates CG-04, CG-07, CG-13, CG-14Domain guide for Building Operations and Service Management
RES controlsResilience, Continuity and Recovery6 families · 24 controls · gates CG-09, CG-10Domain guide for Resilience, Continuity and Recovery
SUP controlsSupply Chain, OEM and Ecosystem Assurance6 families · 24 controls · gates CG-03, CG-15Domain guide for Supply Chain, OEM and Ecosystem Assurance
SEC controlsDigital, OT and Control-Plane Security6 families · 24 controls · gates CG-07, CG-15Domain guide for Digital, OT and Control-Plane Security
EVA controlsEvidence, Assessment and Assurance Management6 families · 24 controls · gates CG-01, CG-02Domain guide for Evidence, Assessment and Assurance Management

Open the domain explorer

Fifteen critical gates

Each gate has its own criteria, an evidence floor, and a ceiling that applies when it fails or is UNKNOWN. In total 106 control-to-gate mappings are CRITICAL and 483 are SUPPORTING, against 101 gate criteria.

CG-01Capability and outcome definition7 critical · 16 supporting controls · 6 criteria

Scope: Capability Instance, Service Outcomes, tolerances, criticality and decision question are defined, owned and approved
Evidence floor: S3
If the gate fails: INCONCLUSIVE for the whole decision: the top claim cannot be framed. The assessment returns to planning (AIDCF-009 DT-02) and no outcome-level decision is issued.
If the gate is UNKNOWN: INCONCLUSIVE for each Service Outcome whose definition or tolerance is UNKNOWN (US5); the remaining outcomes are capped at LIMITED.

CG-02Boundary and architecture integrity3 critical · 16 supporting controls · 6 criteria

Scope: Assessment boundary, current architecture, as-built reconciliation and exclusions
Evidence floor: S3
If the gate fails: If the boundary itself cannot be established: INCONCLUSIVE for the whole decision. If reconciliation demonstrates material divergence in part of the architecture: NOT_ASSURED for claims about the unreconciled systems and LIMITED for the decision as a whole.
If the gate is UNKNOWN: LIMITED. Claims about systems whose reconciliation is incomplete are restricted to the DESIGN claim type.

CG-03Critical dependency visibility9 critical · 50 supporting controls · 7 criteria

Scope: Material internal and external dependencies, common-mode exposure and concentration are identified and owned
Evidence floor: S4
If the gate fails: NOT_ASSURED for every Service Outcome whose redundancy or independence claim is defeated by the identified common mode; LIMITED for the decision as a whole.
If the gate is UNKNOWN: LIMITED. RESILIENCE claims for the affected outcomes are INCONCLUSIVE.

CG-04Life safety and hazardous energy13 critical · 24 supporting controls · 8 criteria

Scope: Fire, electrical arc-flash and shock, hazardous fluids and chemicals, confined space, refrigerants, battery thermal runaway and safe work
Evidence floor: S4
If the gate fails: NOT_ASSURED for any claim relying on the affected area; all hazardous testing in the affected area is suspended; the duty holder is notified immediately (outside the decision process); LIMITED for the decision as a whole.
If the gate is UNKNOWN: LIMITED for outcomes depending on the affected area. No hazardous test is authorised there until the gate is resolved, so EFFECTIVENESS and RESILIENCE claims that need such tests remain UNKNOWN.

CG-05Resilient electrical supply8 critical · 39 supporting controls · 8 criteria

Scope: Utility, distribution, UPS/BESS, generation, fuel, protection and power quality sufficient for the Service Outcomes across operating states
Evidence floor: S5
If the gate fails: NOT_ASSURED for every Service Outcome depending on the affected electrical path; LIMITED for the decision as a whole where unaffected paths remain.
If the gate is UNKNOWN: LIMITED for outcomes depending on electrical continuity; RESILIENCE claims depending on the affected path are INCONCLUSIVE.

CG-06Thermal continuity7 critical · 46 supporting controls · 8 criteria

Scope: Heat-removal path (air, liquid, facility water, heat rejection) sufficient across operating states including transients
Evidence floor: S5
If the gate fails: NOT_ASSURED for Service Outcomes served by the affected heat-removal path at the declared load.
If the gate is UNKNOWN: LIMITED for outcomes depending on the affected heat-removal path.

CG-07Critical control-system integrity6 critical · 26 supporting controls · 7 criteria

Scope: BMS, EPMS, CDU, PLC/SCADA and automation function safely, fail safe, and are configured and governed
Evidence floor: S4
If the gate fails: NOT_ASSURED for Service Outcomes depending on the affected automated function. Claims based on demonstrated manual operation may be assessed separately and support at most LIMITED.
If the gate is UNKNOWN: LIMITED for outcomes depending on the affected automation.

CG-08Compute, storage and network functional integrity12 critical · 63 supporting controls · 7 criteria

Scope: Accelerators, storage and fabrics deliver the required function, performance and integrity
Evidence floor: S4
If the gate fails: NOT_ASSURED for Service Outcomes delivered by the affected cluster, fabric or storage tier. Facility outcomes defined at the rack interface are unaffected.
If the gate is UNKNOWN: LIMITED for the Service Outcomes delivered by the affected cluster, fabric or storage tier.

CG-09Failure containment9 critical · 42 supporting controls · 6 criteria

Scope: Fault domains, isolation and blast-radius limits prevent propagation beyond tolerance
Evidence floor: S4
If the gate fails: NOT_ASSURED for RESILIENCE claims, and for any Service Outcome whose tolerance assumes the defeated containment; LIMITED for the decision as a whole.
If the gate is UNKNOWN: INCONCLUSIVE for RESILIENCE claims of the affected outcomes; LIMITED for the decision as a whole.

CG-10Recovery readiness11 critical · 56 supporting controls · 7 criteria

Scope: Restoration of outcomes (power, cooling, compute, data and checkpoint, network, control plane) within tolerance is planned and tested
Evidence floor: S5
If the gate fails: NOT_ASSURED for recovery outcomes and for RESILIENCE claims of the affected outcomes; LIMITED for the decision as a whole.
If the gate is UNKNOWN: LIMITED; recovery outcomes are INCONCLUSIVE. DESIGN claims about recovery may still be reported.

CG-11Evidence sufficiency0 critical · 0 supporting controls · 6 criteria

Scope: Evidence for decisive claims meets the AIDCF-008 floors (meta-gate across all controls)
Evidence floor: S4
If the gate fails: INCONCLUSIVE for the whole decision. Any previously issued decision relying on the affected evidence is SUSPENDED, and the matter is escalated as an evidence nonconformance (AIDCF-008 §47).
If the gate is UNKNOWN: LIMITED.

CG-12Critical UNKNOWN0 critical · 0 supporting controls · 5 criteria

Scope: No unresolved US4 or US5 UNKNOWN without disposition (meta-gate across all controls)
Evidence floor: S3
If the gate fails: INCONCLUSIVE for the whole decision; escalated as an evidence nonconformance (concealed UNKNOWN, AIDCF-008 §47).
If the gate is UNKNOWN: LIMITED; INCONCLUSIVE if any undispositioned UNKNOWN is US5.

CG-13Responsibility and authority7 critical · 28 supporting controls · 6 criteria

Scope: Every critical function and dependency has an accountable owner and decision authority
Evidence floor: S3
If the gate fails: NOT_ASSURED for OPERATION, EFFECTIVENESS and RESILIENCE claims about the unowned function or dependency; LIMITED for the decision as a whole. If GC-13-6 is not met, no decision advances beyond the RECOMMENDED lifecycle state.
If the gate is UNKNOWN: LIMITED.

CG-14Change control7 critical · 35 supporting controls · 7 criteria

Scope: Material changes are controlled, impact-assessed and validated
Evidence floor: S4
If the gate fails: Affected evidence is invalidated (STALE, U3) and claims relying on the post-change state become UNKNOWN; any prior decision covering the affected scope is SUSPENDED; LIMITED for the decision as a whole, or NOT_ASSURED where the uncontrolled change is demonstrated to have defeated a safeguard.
If the gate is UNKNOWN: LIMITED.

CG-15Integrated digital authority over infrastructure7 critical · 42 supporting controls · 7 criteria

Scope: Identity, privilege, remote access and control-plane reach over facility and AI infrastructure are bounded, monitored and recoverable
Evidence floor: S4
If the gate fails: NOT_ASSURED for every Service Outcome reachable through the unbounded authority path; LIMITED for the decision as a whole.
If the gate is UNKNOWN: LIMITED; INCONCLUSIVE where the unverified authority reaches the scope of two or more other gates (US5).

Validation status

What has been done, what has been prepared, and what is still needed before anyone should rely on AIDCF.

20 reference failure patterns in the methodology, 12 instantiated in the synthetic case, and no completed real-world assessment recorded.

Done: Canonical control baseline published: 15 domains, 90 families, 360 controls (registry v1.0, approved baseline).
In progress: Registry v1.1, which makes every control testable, is proposed under amendment AMD-002 and not yet approved.
Done: Synthetic reference implementation passes 13 validation layers (15,457 checks). This is self-validation by the author's tooling, not independent execution.
In progress: Incident back-test (AIDCF-VAL-001): protocol prepared and comparison instruments implemented (v1.1, draft). The three pilot comparison profiles (commissioning, engineering studies and OT security risk assessment) are awaiting practitioner approval. The sample has not been drawn. No results are available.
Not started: Independent multidisciplinary review. Not started.
Not started: Authorised pilot on a real facility. Not started; the pilot pack is ready.
Not started: Inter-rater reproducibility trial. Not started.
Not started: DOI for the whitepaper. Not yet minted.

Validation instruments

Validation instruments and their state
Instrument	Question it tests	State
Incident back-test (AIDCF-VAL-001)	Would AIDCF have flagged the causes of real, publicly reported outages, and would conventional reviews have flagged them too?	Protocol v1.0 in force. Draft v1.1 adds the comparison with conventional reviews, and its instruments are implemented. The three pilot comparison profiles await practitioner approval; the other three methods are not in the initial pilot. Sampling frame: 221 incidents logged, 137 eligible, 84 excluded with reasons. Sample not drawn. No results.
Expert panel (AIDCF-VAL-002)	Do independent specialists agree the controls and gates are relevant and clear?	Kit ready: 48 sampled controls and 15 gates. Panel not yet recruited.
Mini-pilot (AIDCF-PIL-001)	Can AIDCF be applied to a real facility, and at what cost?	Pack ready: a 58-control starter profile and a 274-item evidence request list. No host facility yet.
Independent review	Does the method stand up to power, cooling, HPC, OT security and assurance specialists?	Not started. Reviewers are invited.

Research and artifacts

The GitHub repository is the canonical source. This site is generated from it at a pinned commit.

Technical whitepaper v3.1

AIDCF: AI Data Centre Facilities Assurance Framework. Technical Whitepaper v3.1, Validation Candidate for Independent Review.

PDF Markdown

SHA-256 of the PDF at commit 8b0a941:

2ba438aacc0ee4565e8e93baca0a94eddd0f2478d052be4c1acb11585fb08f7b

How to cite

A DOI has not been minted yet; cite the repository and release.

Sethumadhavan, S. (2026). AIDCF: AI Data Centre Facilities Assurance Framework. Technical Whitepaper v3.1, Validation Candidate for Independent Review (Release AIDCF-REL-2026.10.1). https://github.com/Sivas1187/AIDCF

BibTeX

@techreport{sethumadhavan2026aidcf,
  author      = {Sethumadhavan, Siva},
  title       = {AIDCF: AI Data Centre Facilities Assurance Framework. Technical Whitepaper v3.1, Validation Candidate for Independent Review},
  year        = {2026},
  number      = {AIDCF-REL-2026.10.1},
  url         = {https://github.com/Sivas1187/AIDCF},
  note        = {Version 3.1}
}

All documents, data and resources