Stranded Power Risk in Phased Campus Development

Stranded power used to mean one thing: capacity that looks available on paper but isn't, tied up in a grid queue, committed to somebody else's project, or blocked by congestion the utility can't fix on your timeline. That's the definition Acres used in July 2025, and it still holds. Phased campus development has produced a second, meaner version of the term, though: now stranded power can also mean capacity that was already committed, already paid for, sitting unused because the next phase got stuck behind a permit, a transformer with an 18-month lead time, or a design team that never checked its numbers against the team next door.

Site-selection stranded power is a risk taken before contracts get signed. Phased-delivery stranded power is a liability carried after the ink's dry, and it keeps costing money whether or not anyone's watching it.

U.S. IT load capacity is around 80 gigawatts today. Bloom Energy's 2026 Data Center Power Report projects that climbing to roughly 150 gigawatts by 2028, and most of that growth comes from campus expansions: phase 3s and phase 4s bolted onto footprints that already exist, not brand-new sites in unfamiliar markets. Developers have decided, reasonably, that expanding what they already have beats betting on new geography. That instinct is the right hedge against grid risk. But it's quietly building a different kind of risk, one that has nothing to do with the utility and everything to do with how well a developer's own teams talk to each other across phases.

The asymmetry between construction speed and power delivery that makes every phase a timing gamble

A data center can go up in 12 to 18 months. Bessemer Venture Partners' BVP Atlas research finds that grid interconnection currently takes 5 to 7 years. That gap is the mismatch behind nearly every problem in this piece.

Power has to get locked in years before anyone pours a slab. Once it's locked in, every month of delay on the deployment side turns into a month of paying for capacity nobody's using.

Campuses used to ramp gradually, commissioning power in stages and growing into it over time. That assumption is breaking down fast. AI workloads are increasingly driving operators to have full capacity available from the start rather than ramping gradually, which kills the old playbook of commissioning incrementally and filling it in later. A developer either has power ready when the racks show up, or gets stuck holding capacity it can't use, sitting next to hardware it can't run. There's no comfortable middle anymore.

Interconnection delays are running long even against expectations that were already stretched thin. EnkiAI reported that delays exceeding three years now count as a primary business risk, and Bloom Energy's report found utility respondents expecting time-to-power to run 1.5 to 2 years longer than hyperscalers and colocation providers are planning for. That gap between expectation and reality is sharpest in the markets where campus buildout is heaviest right now.

Industry analysts have flagged power shortages as a primary constraint on AI data center deployment in the near term. Once a meaningful share of phased campus projects hit a wall where committed power can't be deployed on schedule, stranded power becomes a line item because there's nothing to run against it: carrying costs and committed capacity with no offsetting use.

Once external timing pressure gets this tight, the real question turns inward. Does the coordination inside the project absorb the shock, or make the delay worse?

Disconnected power, load, and phasing documents instead of a coordinated system

Energy strategy needs to get built into the earliest planning phases now, not bolted on after site selection. That point is consistent with guidance from practitioners and researchers tracking data center development constraints. In practice, though, the documents meant to carry this strategy rarely talk to each other.

Utility agreements and interconnection studies live with one team. Power density schedules and capacity models sit with the MEP engineers, usually in spreadsheets or specialized load-math tools. Layout lives in CAD or BIM. Phasing lives in a Gantt chart or a project management tool, often exported to PDF for review. None of these systems share data natively. The power budget the utility agreed to isn't linked to the rack load schedule the MEP team is building, and neither one is linked to the construction sequence the general contractor is managing.

Each document is a snapshot, accurate the day someone wrote it. As the project evolves, each one gets updated on its own schedule, by its own team, and the space between them grows invisibly until a phase milestone forces everyone to compare notes. No single document is wrong when that happens. Three defensible documents, each built on assumptions about density, timing, and committed load that were never checked against each other, can still add up to a mess nobody intended.

Rack density is widening that gap fast. Traditional racks ran 5 to 15 kW. EnkiAI reports AI-optimized racks now run 30 kW to over 100 kW, and Deloitte's research points to next-generation AI racks potentially hitting 370 kW. A load schedule written during phase 1 planning can go stale by the time phase 2 breaks ground for one simple reason: the chips changed underneath it.

A single rack density revision's cascade into stranded capacity across a campus phase

A density revision is a routine engineering update. Nobody panics when it happens. The trouble starts when that update has nowhere automatic to go.

Take phase 2's layout getting revised to fit higher-density AI racks. The layout team updates the floor plan, does its job well, moves on. But the power budget sitting inside the utility agreement still reflects the original, lower-density assumption from months earlier. Nobody lied, nobody was careless. The gap just sits there, invisible, until energization planning starts and somebody realizes the committed power envelope is now undersized for what's actually going into the building. By then the schedule is already built around the old number.

Running the scenario the other direction flips the shape of the problem, but not the outcome: density gets revised downward, or a phase slips, and the committed capacity for that phase ends up bigger than what's actually needed. The surplus sits there costing money with nothing to show for it. That's stranded capacity in its purest form.

The amortization math makes this close to unavoidable. Physical data center infrastructure amortizes over 15 to 20 years. New AI accelerator generations show up every 12 to 18 months, according to ArXiv research. Setting those two numbers side by side leads to a clear conclusion: density assumptions made at the start of a campus buildout will get revised, probably more than once, before the last phase finishes. Each revision is a potential stranded-capacity event, unless somebody manually reconciles every document that touches it.

Power isn't the only thing that ripples, either. A density change touches cooling system sizing, cable tray capacity, and PDU specs, each one likely sitting in a different document, owned by a different team. As campuses scale toward gigawatt territory, and Bloom Energy's 2026 report puts roughly 1 in 5 campuses at that scale by 2030, the number of interdependent changes in flight at once multiplies right along with it.

Why phased delivery compounds these gaps across phases rather than resetting them

A single-phase project gets one shot at this failure. A reconciliation gap gets caught at handoff, somebody loses a week fixing it, and the damage stays contained to that one project. Phased campus delivery doesn't get that mercy.

Phase 1's documents become the starting assumptions for phase 2. If those documents carry unreconciled gaps between committed power and deployable load, phase 2 inherits the gap along with everything else. Worse, the planners working on phase 2 usually see only the finished outputs: drawings, power schedules, equipment specs, not the decision history behind them. They have no way to tell which numbers were actually validated and which just got carried forward because nobody flagged them.

Then phase 2 stacks its own revisions on top: new density assumptions, equipment swaps, schedule shifts. Each one is a new layer sitting on gaps that were already there. By the time a large campus reaches phase 3 or phase 4, the distance between the power infrastructure as designed and the power infrastructure as actually committed and deployable can be substantial. And it stays invisible, because no single document ever captured the whole picture at once.

The buildup is slow and quiet. It appears in a phase energization milestone, a utility audit, or a DCIM commissioning exercise, when one of these finally forces everyone to lay four phases of paperwork side by side. At that point the cost goes beyond the stranded capacity itself. Reconciling documentation that was never built to connect adds further rework. ArchiLabs has pointed out that something as simple as a rack move can ripple manually across power, cooling, cable, schedules, and sheets, which is exactly the kind of problem this compounding produces at scale.

Power constraints already stand between data centers and growth more than anything else in the business, and Data Center Knowledge reported that stranded power represents straightforward lost revenue. Multiplying that gap across four phases means it stops being an engineering headache. It turns into a balance sheet problem.

What connected, structured coordination across power modeling, layout, and phasing requires

Better documents aren't the fix. One shared data model is, where a change in power, layout, or phasing propagates to the other two without anyone re-typing numbers into a second spreadsheet.

Power budget has to stay linked to rack layout continuously, not reconciled once at energization. If a phase gets deferred, the load planned against that phase's committed capacity should appear immediately as an at-risk gap in the tracking system; it should not surface months later when the expected power draw never materializes. When a density assumption changes in the layout, the power budget, the cooling schedule, and the PDU specs need to update on their own, deterministically. This is rules-based math, and precision here isn't optional. Guesswork has no place in it.

Every committed allocation, every density assumption, every phasing call needs to trace back to whatever justified it, so when something changes, the downstream effects appear in the system instead of sitting buried three folders deep in someone's version history. Phase handoffs need to carry live, queryable data forward that the next team can access directly. That's also where BIM data tends to fail: arriving at turnover disconnected from operations instead of flowing cleanly into the DCIM, EPMS, and BMS systems that actually run the building.

How ArchiLabs Studio connects the systems that fragmented workflows leave apart

ArchiLabs Studio was built around exactly this problem: layout, power and cooling coordination, cable routing, documentation, RFIs, and operations-ready handoff, all inside one connected workflow instead of five disconnected ones.

The link between layout and power isn't an add-on feature. Moving a rack in Studio updates power, cooling, cable, and documentation automatically inside the same data model, the same cascade that costs hours of manual rework everywhere else. Committed capacity and deployable load share that model instead of living in separate files, so teams can watch a stranded-capacity condition start to form before it turns into a phase-boundary crisis nobody saw coming.

Deterministic rules, not AI guesswork, handle the precision-critical math: density validation, compliance checks, load reconciliation. That split is deliberate. AI-assisted work fits tasks like layout generation or drafting an RFI, where some ambiguity is tolerable. Power allocation math isn't one of those tasks, and treating it like one is how stranded capacity happens.

Phase handoffs produce structured data instead of PDFs, so when a phase goes operational, the DCIM, EPMS, and BMS integrations mean nobody's re-entering asset data that already existed somewhere else. Equipment specs from manufacturers flow straight into the model and its validation rules, which matters a lot when rack generations turn over every 12 to 18 months. None of this replaces the tools teams already use. It connects them, so one change doesn't spin off a manual update campaign across four other systems.

The early-phase coordination disciplines that prevent stranded capacity from compounding across a campus build-out

A handful of disciplines separate campuses that avoid this problem from campuses that discover it the hard way, usually at the worst possible moment.

Keep one power budget document, live and linked, showing committed capacity, planned load, and the gap between them at all times, not just when somebody remembers to check.

Re-validate density assumptions at every phase gate, not only at the start. AI-optimized rack density already spans 30 kW to over 100 kW, so whatever density assumption was true at phase 1 needs an explicit recheck before it becomes the baseline everyone builds phase 2 around.

Build the phasing schedule from the power model itself, not next to it. Schedules written independently of the power numbers always need reconciliation later, while schedules written against the power model reveal conflicts while they're still cheap to fix.

Track the gap between committed capacity and deployable load as a running project metric, not something checked only at energization. A delay anywhere in the sequence should register as a stranded-capacity risk immediately, not get discovered three months on.

Require every phase handoff to carry queryable data instead of static PDFs, so the next team sees the assumptions behind a number and not just the number itself. Connect RFI and submittal approvals directly to the power and layout model, too: an equipment substitution approved through an RFI should update the power budget and load schedule the moment it clears, not on the next manual review cycle.

The interconnection timeline, 5 to 7 years against a 12-to-18-month build, leaves almost no room to catch stranded capacity late. Every month of delay against power that's already committed and already being paid for makes the eventual correction more expensive. The developers who deliver gigawatt-scale campuses without bleeding money to this problem will be the ones who treat power budget integrity as a design discipline from the first planning meeting.