Category definition
What is a virtual capacity control plane?
An AI Data Center Virtual Capacity Control Plane is an inside-the-fence capacity-acceptance layer. It coordinates workloads, cooling, storage, and on-site power, then uses runtime assurance to allow, repair, or reject proposed actions inside explicit safety and SLA envelopes. Its output is proof-backed virtual capacity—not a forecast, dashboard score, or promise of unconstrained power.
Definition
What it is
The control plane continuously evaluates whether requested capacity can be admitted and dispatched across coupled facility constraints. It binds every accepted action to a dispatch envelope, margin-to-limit record, and replayable proof artifact.
Category boundary
What it is not
It is not a DCIM replacement, generic energy management system, demand-response aggregator, or digital twin category. Those systems can supply observations or models; they do not, by themselves, accept capacity under a deterministic runtime authority boundary.
Operational significance
Why operators care
Operators need a defensible answer to a concrete question: which additional MW can be used now, for this workload and duration, without violating facility limits or protected SLAs? A capacity control plane makes that answer inspectable before bounded autonomy expands.
Mechanism
How the decision path works
- Step 01
Observe topology, workload demand, thermal state, reserve posture, and telemetry freshness.
- Step 02
Construct candidate actions across workloads, cooling, storage, and bridge-power assets.
- Step 03
Evaluate candidates against the dispatch envelope and binding constraints.
- Step 04
Allow, repair, reject, or return no-proof; record evidence and remaining margin.
- Step 05
Replay the decision in Shadow Mode before any authority expansion.
Textual diagram equivalent
Decision flow
Telemetry and topology → candidate capacity request → cross-domain model → runtime assurance gate → allow / repair / reject / no-proof → accepted-headroom ledger and proof pack.
Synthetic acceptance example
Visibly scoped example
Synthetic illustrative scenario—not a customer or production result. A request for additional AI workload is repaired to a smaller, time-bounded action because the reserve floor becomes the binding constraint. The accepted action carries its constraint trace and rollback posture.
Failure and no-proof cases
- Telemetry is stale or internally inconsistent.
- The modeled topology does not match the operating topology.
- A reserve, thermal, water, or SLA margin cannot be proven.
- The rollback path is unavailable or outside the permitted authority boundary.
Limitations
- Virtual capacity cannot substitute for physical interconnection, equipment, fuel, cooling, or maintenance capacity.
- An accepted action is scoped to its stated topology, operating window, policy, and evidence freshness.
- The control plane begins in Shadow Mode and does not imply autonomous control authority.
Evidence and sources
Inspect the basis, not just the answer
Local evidence objects show the GridNinja proof contract. Primary sources provide external standards and risk-management context; they do not validate GridNinja performance.
Related operator resources
Continue the proof path
- The platform for runtime-assured virtual capacitySee how GridNinja coordinates workloads, cooling, storage, and bridge power inside a runtime-assured dispatch envelope.
- Trust starts with boundariesSee how Shadow Mode, replay, allow / repair / reject decisions, audit logs, and proof packs establish evidence before bounded autonomy.
- Quantify proof-adjusted capacity before you promise flexible MWRequest a Capacity Audit to quantify proof-adjusted safe MW, time-to-power, constraints, evidence gaps, and potential commercial value.
Proof before autonomy
Test the evidence boundary against your capacity question
Start with a Capacity Audit or read-only Shadow Mode discussion. GridNinja does not require control authority to identify where a capacity claim remains unproven.