Skip to content
GridNinja
Request Audit

Shadow comparison

Turn this diligence path into a read-only Capacity Audit

Request Capacity Audit

The capacity-acceptance layer

Before you trust another megawatt, ask what proves it.

GridNinja sits between a capacity claim and operator acceptance. It tests the claim against electrical, cooling, storage, workload, water, telemetry, and policy constraints, then returns allow, repair, reject, or no-proof with replayable evidence.

Run the 10-point proof testInspect a sample proof pack
official-source comparisonsevidence maturity shownread-only first

Capacity acceptance trace

Possibility becomes proof

idle

Claimed headroom

18.4 MW

Checked against

site constraints

Proof-adjusted MW

1.1 MW

RTA output

REPAIR

split correction

requested

2.4 MW

accepted

1.1 MW

Reason: Preserve operator-declared UPS reserve floor.

Constraint gates

The summary shows the acceptance result first. Inspect the gates to see which site-local constraints changed the MW claim.

Proof written

proof_row_004921

topology v0.3 / policy shadow_read_only

Read-only first
No command VLAN
No write credentials
Four-state runtime assurance
Replayable evidence

Crawlable source index

Every comparison source has a stable public anchor

These links expose the reviewed public materials behind the comparison. They establish only the scoped facts recorded for each source; they do not imply unsupported performance, customer, or authority claims.

  1. Emerald AI · retrieved June 18, 2026

    Emerald AI homepage

    Establishes: Grid-facing AI flexibility, workload coordination, on-site energy coordination, fleet-level flexibility, and measurement reporting are central public themes.

    Does not establish: This source does not establish a GridNinja-style site-local accepted-headroom ledger, four-state RTA contract, or no-proof register.

  2. Emerald AI / Silicon Valley Power · retrieved June 18, 2026

    SVP flexible data center pilot announcement

    Establishes: Emerald has public utility-pilot positioning around flexible operations, SVP signals, and AI workload performance protection.

    Does not establish: The announcement does not define GridNinja's acceptance contract, proof-row model, or no-proof behavior.

  3. Phaidra · retrieved June 18, 2026

    Phaidra homepage

    Establishes: Power, cooling, workload management, and tokens-per-watt AI factory outcomes are public Phaidra themes.

    Does not establish: This source does not describe GridNinja's four-state runtime assurance, accepted-headroom ledger, or proof-pack contract.

  4. Phaidra · retrieved June 18, 2026

    Phaidra Factory product page

    Establishes: Thermal stability, stranded power, compute footprint, time-to-first-token, and integrated AI factory operations are public themes.

    Does not establish: The page does not define an accepted-headroom accounting layer or no-proof evidence register.

  5. Schneider Electric / ETAP / NVIDIA · retrieved June 18, 2026

    AI Factory power digital twin announcement

    Establishes: Design, simulation, what-if analysis, real-time electrical infrastructure insight, and predictive maintenance are public themes.

    Does not establish: It does not establish GridNinja's site-local four-state acceptance contract or accepted-headroom ledger.

  6. NVIDIA · retrieved June 18, 2026

    Omniverse DSX Blueprint overview

    Establishes: Interactive digital twins, thermal/electrical simulations, and design-through-operation workflows are public DSX Blueprint themes.

    Does not establish: The docs do not make GridNinja's accepted MW, no-proof, or proof-pack claims.

  7. Sunbird DCIM · retrieved June 18, 2026

    Data center capacity management

    Establishes: Asset and capacity visibility, 2D/3D planning, and multi-resource analysis are central DCIM themes.

    Does not establish: This source does not define a GridNinja-style runtime assurance decision or proof-adjusted dispatch envelope.

  8. Sunbird DCIM · retrieved June 18, 2026

    Data center power management

    Establishes: Power visibility, monitoring, planning, and multi-vendor infrastructure views are public Sunbird themes.

    Does not establish: This source does not establish GridNinja's allow / repair / reject / no-proof decision model.

  9. GridNinja · retrieved July 11, 2026

    Proof Before Autonomy standard

    Establishes: GridNinja's stated responsibility is to turn a capacity claim into a policy-bound acceptance decision with evidence, rather than to replace every system that produces an input.

    Does not establish: This internal source does not establish a competitor's public capability or validate a GridNinja claim for every site.

  10. Enel X · retrieved July 11, 2026

    Demand Response

    Establishes: Market access, programme enrolment, dispatch operations, flexibility measurement, and commercial value are credible public responsibilities for a demand-response provider.

    Does not establish: This representative source does not establish identical capabilities for every market-access provider or a GridNinja-style inside-the-fence acceptance contract.

  11. Eaton · retrieved July 11, 2026

    Brightlayer DCIM software

    Establishes: Critical-infrastructure suites can provide monitoring, management, lifecycle context, capacity visibility, and integration across facility systems.

    Does not establish: This representative source does not establish a vendor-neutral GridNinja acceptance layer or equivalent capabilities across every hardware and infrastructure vendor.

Category role map

Strong systems already solve important parts of the problem

GridNinja works with the data-center stack. Its distinct responsibility begins where a capacity claim needs a site-local acceptance decision.

DCOutput: Site context

DCIM

Observe, inventory, plan, model, and monitor infrastructure.

GridNinja use: Constraint and topology input.

DTOutput: Modeled possibility

Digital Twin

Simulate designs, operating conditions, and what-if scenarios.

GridNinja use: Scenario and design input.

AIOutput: Optimized proposal

AI Operations

Tune cooling, power, workloads, reliability, and efficiency.

GridNinja use: Candidate action input.

GridNinja acceptance boundary: verify / RTA / policy / proof

The missing layer

A useful recommendation still needs a site-local acceptance decision

GridNinja does not need to own every sensor, model, controller, or market relationship. It owns the acceptance contract linking a claim to local evidence.

Inputs

Existing systems and requests

DCIM capacity and topology
BMS / EPMS telemetry
Digital-twin outputs
UPS / BESS state
Cooling and water state
Workload scheduler
Grid or aggregator request
Operator policy

GridNinja boundary

Local acceptance logic

Telemetry quality gate
Topology and constraint model
Deterministic verification
Runtime assurance
Operator policy enforcement
Receipt validation
Replay eligibility
No-proof discipline

Outputs

Accepted evidence objects

Proof-adjusted MW
Dispatch envelope
Accepted-headroom ledger
No-proof gap register
AI Factory Load Passport
Safe reconnection envelope
Utility evidence packet
Proof pack

Buyer diligence

The 10-point Virtual Capacity Proof Test

GridNinja should be judged by the same evidence standard it asks buyers to apply to the market.

Proof requirement 01

Read-only Shadow Mode

Buyer question

Can the system demonstrate decisions without live authority?

The first proof posture should not require write credentials, command VLAN access, or hidden actuation.

Weak answer

A sandbox demo disconnected from real site telemetry.

Strong answer

A productized, read-only deployment using current telemetry, topology, and policy with no command credentials.

GridNinja artifact

shadow_decision_tape.jsonl

SHA256

6bc9...f12a

scope

shadow_read_only

authority

no write path

Evidence maturity applies to the defined Shadow Mode implementation and scenario, not every possible site topology.

Fair comparison

Compare roles, evidence, and authority boundaries

Cells summarize primary public positioning, not every possible vendor capability. Source drawers sit behind the comparison so diligence does not depend on marketing shorthand.

Capability 1 / 8

Asset and capacity visibility

DCIM

CORE

GridNinja

INTEGRATION INPUT

Public positioning reviewed as of June 18, 2026. Not central and public detail varies do not mean unavailable; they mean the public material reviewed here does not make that function the primary evidence standard. GridNinja claims are limited to the maturity shown.

Named profiles

Respect the strengths. Define the responsibility.

Each profile separates what official materials clearly establish from GridNinja's narrower acceptance-layer thesis.

Positioning invariant

Models rank. Solvers verify. Runtime assurance decides. Proof makes the capacity claim durable.

Active profile

Emerald AI

Grid-facing AI flexibility and orchestration

A credible grid-flexibility profile. GridNinja should distinguish itself through site-local acceptance, runtime assurance, and proof-rooted headroom accounting.

Responsibility map

Where the public profile ends and GridNinja begins.

Public profile Shared GridNinja
  1. 01Observe
  2. 02Model
  3. 03Propose
  4. 04Verify
  5. 05RTA
  6. 06Account
  7. 07Prove

What public materials show

Grid connectivity, workload and on-site energy orchestration, fleet flexibility, digital-twin modeling, and auditable measurement and verification.

Shared terrain

Data-center flexibility, workload coordination, measurement, and grid-facing value.

GridNinja responsibility

Site-local acceptance: deterministic constraint verification, four-state runtime assurance, no-proof exits, accepted-headroom accounting, receipts, and replay evidence.

Proof GridNinja must produce

Cross-domain Shadow Mode replay, reserve-floor traces, operator-reviewed ledgers, stable proof roots, and examples where facility constraints require repair or refusal.

Grid flexibilityM&VWorkload modulation

Category boundary

Others optimize, simulate, monitor, aggregate, or bundle. GridNinja verifies what can safely become usable capacity.

Architecture of dependence

A common acceptance record turns multiple tools into one defensible decision

The strongest indispensability claim is architectural: remove the record and the stack loses a shared definition of trusted capacity.

Without common acceptance record

Useful systems, fragmented MW values

External request: 4.0 MW / 20 min

DCIM: 6.2 MW available
Scheduler: 4.8 MW flexible
BESS: 3.9 MW discharge
Cooling model: 5.4 MW thermal margin
Aggregator request: 4.0 MW asserted
No common accepted value

With GridNinja

One proof-linked accepted envelope

Versioned claim

4.0 MW / 20 min

allow

Reserve-floor repair

-1.1 MW

repair

Telemetry discount

-0.4 MW

repair

Cooling margin

accepted

allow

SLA policy

accepted

allow

Accepted envelope

2.5 MW / 20 min

RTA traceDispatch envelopeAccepted-headroom ledgerProof root

Indispensability conditions

When the acceptance layer becomes operationally essential

Dependence emerges when multiple stakeholders need the same bounded, inspectable definition of capacity.

01 / GRID REQUEST

External flexibility must respect local limits.

A utility or aggregator request cannot resolve UPS reserve, cooling margin, workload SLA, rebound risk, and operator policy by itself.

RTA trace + dispatch envelope

02 / CONFLICTING HEADROOM

Multiple systems produce different MW values.

Operations, commercial teams, and fleet software need one versioned definition of accepted capacity.

Accepted-headroom ledger

03 / TELEMETRY TRUST

Evidence quality varies by subsystem.

Capacity should degrade explicitly when telemetry is stale, incomplete, misaligned, or topologically ambiguous.

No-proof gap register

04 / FLEET AGGREGATION

Sites need comparable local envelopes.

Fleet-level capacity becomes credible only when each site contributes a locally accepted, versioned envelope.

FleetOS registry

05 / STORAGE-BACKED MW

Commercial flexibility must preserve emergency reserve.

UPS and BESS partners need a clear boundary between available support and protected resilience capacity.

Reserve-floor report

06 / DILIGENCE

Buyers need more than claimed MW.

Investors, operators, and partners must distinguish nominal, modeled, replay-validated, and operator-accepted capacity.

Load Passport + proof pack

Proof room

Every differentiating claim should open into evidence

A claim without scope, maturity, date, artifact, and caveat should not appear on the public page.

CW

Capacity Waterfall

Nominal headroom reduced through explicit constraint layers.

8f4c...91a
RT

RTA Decision Trace

Allow, repair, reject, and no-proof with reasons and margins.

004921
BC

Binding Constraint Report

Constraint identity, source quality, threshold, and post-action state.

T2
NP

No-Proof Register

Missing or stale evidence and its impact on accepted capacity.

3 gaps

Why it matters

One acceptance record, different stakeholder value

The page lets each audience find its own proof path without changing the underlying product truth.

Selected audience

Operator

See the binding constraint, inspect every repair, keep authority local, and return no-proof when evidence is weak.

Binding constraint trace
RTA repair history
Accepted-headroom ledger
No-proof register
Compare this proof path
Comparison methodology and source governancedisclosure

Comparisons describe primary public positioning reviewed on the stated date. They do not assert that a vendor lacks every capability absent from public materials. GridNinja claims show evidence maturity, scope, validation date, and caveats.

Review sources

Related operator resources

Continue the proof path

Site-specific proof

Compare GridNinja on your site, not on a feature sheet.

Start with a read-only shadow assessment. Map constraints, identify no-proof gaps, replay candidate actions, and produce an operator-reviewable capacity evidence packet.

Run a shadow comparisonInspect sample proof pack

Shadow assessment boundary

  • No command VLAN
  • No write credentials
  • No live actuation
  • Operator-readable proof artifacts
  • Evidence maturity and caveats shown