How an AI infrastructure provider deploys a new site
A 34-stage illustrative lifecycle from demand forecast to operations handover, with stakeholders, RACI, dependencies, risks and commissioning checklists.
A new AI site is not a technology project with some construction attached. It is a construction and utility programme with a technology project inside it, and the sequencing reflects that. The stages below run from demand forecast to capacity expansion; the explorer lets you open each one to see where it typically goes wrong.
The lifecycle
Illustrative AI infrastructure provider deployment model based on public information and common industry practice. It does not describe any provider's actual or confidential process. No durations are given — they vary by region, market and grid conditions.
Demand & planning
Site & commercial
Design
Build & install
Bring-up & test
Acceptance & operate
Four things that decide the outcome
1. Power is usually the long pole
Hardware can often be procured faster than a grid connection can be delivered. A site selected on commercial terms and then found to be unbuildable on the required timeline invalidates the entire plan — and that discovery frequently happens after commitments have been made. Confirming the connection timeline in writing belongs before signing capacity commitments, not after.
2. Demand must be contracted, not forecast
3. The facility must support the platform, confirmed early
A rack-side cooling design is a property of the platform. What sits above the CDU is a property of the site. Confirming that the facility loop can accept the heat at the required supply temperature is a design-stage activity — discovering it during commissioning means either a facility retrofit or a platform change, both of which are expensive at that point.
4. Redundancy that was never tested does not exist
Resilience testing — deliberately failing links, switches, power feeds, CDUs and nodes to confirm behaviour matches design — is the acceptance gate most often compressed under schedule pressure. Untested redundancy is an assumption, and it tends to be discovered as an assumption during the first real incident.
Why staging and burn-in earn their place
| Stage | What it catches | What happens if it is cut |
|---|---|---|
| Factory staging | Integration, cabling and firmware faults, in a controlled environment with tooling and spares to hand. | The same faults are found in the data hall, where diagnosis is slower, access is constrained and the schedule is already tight. |
| Firmware baselining | Version divergence across nodes before it can cause anything. | Intermittent faults appear weeks later and are extremely hard to attribute to their cause. |
| Burn-in | Early-life component failures, and thermal or power problems that only appear under sustained load. | Infant-mortality failures move into production and hit customer workloads instead of the commissioning window. |
| Performance testing | Stragglers — devices running measurably slower than their peers. | A synchronous job is paced by its slowest participant, so aggregate acceptance numbers hide a permanent tax on every job. |
| Resilience testing | Redundancy that does not actually work. | The first real failure becomes the test, during an incident, with customers watching. |
Illustrative. The specific gates and their pass criteria are set per programme, and defining them precisely enough to pass or fail is itself part of the work.
Integrators stage this work in levels: L10 proves each server, L11 each cabled rack, L12 the cluster as one system. Which tests run at each level, with which tools and by whom, is set out in 4.2 Testing and validation.
Stakeholders
Twenty-one distinct parties appear in the RACI view of the explorer above, from the utility and local authorities through to the service-delivery manager who inherits the result. Two observations are worth drawing out.
Capacity expansion
Stage 34 is not an afterthought; it is a design constraint that applies from stage 11. Adding racks or pods into a live environment without disrupting running workloads depends on the original network scale unit having been chosen with growth headroom, and on the facility agreement having contracted expansion rights. Neither can be retrofitted cheaply.
Key Takeaways
- A new AI site is a construction and utility programme with a technology project inside it.
- Grid connection and substation capacity usually dominate the schedule, ahead of hardware procurement.
- Capacity plans built on uncontracted pipeline are how sites end up stranded.
- Facility cooling capability must be confirmed against the platform at design stage, not discovered at commissioning.
- Factory staging moves integration faults out of the data hall, where they are far more expensive to fix.
- Aggregate performance acceptance can hide stragglers, which permanently tax every synchronous job.
- Untested redundancy is an assumption; resilience testing is the gate that converts it into a fact.
- Accountability crosses organisational boundaries throughout — the provider owns the outcome but controls little of the critical path.
- Expansion headroom is a stage-11 design decision and a contract term, not a stage-34 problem.