METHOD NOTE v2.1

Large-load constraint screening: units, evidence, scenarios and release checks.

This note documents the public decision logic behind an ORBIT Large-Load Site Constraint Screen. Patent-sensitive implementation details are intentionally omitted. The purpose is to make the analysis auditable without implying that public methodology replaces site validation, utility commitments, permit review or licensed engineering.

1. Define the load correctly

IT MW and facility MW are different quantities.

incremental facility MW = incremental IT MW × selected PUE

A screen should state both values and keep them separate in every capacity comparison. For example, 32 MW of incremental IT load at PUE 1.25 corresponds to 40 MW of incremental facility demand.

2. Quantify each resource in its own units

Do not subtract unlike quantities.

Power

Headroom = committed incremental facility capacity - cumulative incremental facility demand.

Negative headroom means the modeled incremental service is insufficient for that phase.

Cooling

Cooling load = existing peak cooling load + cumulative IT MW × heat-rejection factor.

The comparison is MWth-to-MWth, not a percentage derived from unrelated facility MW.

Water

Water demand = existing peak water demand + cumulative IT MW × selected water-intensity assumption.

The selected cooling architecture can change water intensity and therefore the conclusion.

Wastewater

Hydraulic capacity and discharge quality are separate screens.

Adequate hydraulic headroom does not establish compliance with local limits or pretreatment requirements.

3. Evidence states

Known, stated, modeled and unknown are not interchangeable.

StateTreatment
Source-linked factRetain a source pointer, date/page/row where practical, and evidence quality.
Customer-statedUseful input, but not independently verified.
Modeled estimate / assumptionShow the formula, range and sensitivity where material.
UnknownKeep it unknown; use it to narrow the conclusion or trigger next evidence.
4. Scenario discipline

Low should be a downside case, not merely a cheaper case.

For economics, a conservative case should combine lower benefit with higher cost where those conditions can plausibly occur together. A base case should use the central assumptions. An upside case may combine higher benefit with lower cost only when there is a defensible basis.

PV of future CAPEX = CAPEX / (1 + discount rate)^deferral years
economic benefit of deferral = current CAPEX - PV of future CAPEX

Deferring $3.2M is not the same as avoiding $3.2M. ORBIT treats time value explicitly.

5. Value-state discipline

Unapproved modeled value is not Forecast and is not realized value.

ORBIT may identify and model a potential economic effect. Until an initiative is approved, the value remains Identified / modeled. After approval it may enter Forecast. Only measured and evidenced outcomes can become Verified Realized in the YIELD lifecycle.

6. G2 arithmetic release gate

A report should not ship if its workbook disagrees with it.

Required checkRelease expectation
Phase totalsIT, facility, cooling, water and wastewater totals reconcile.
Constraint statusReported bind phase matches model status and headroom sign.
UnitsIT MW, facility MW, MWth and gpm are explicit and not mixed.
EconomicsDiscount rate is actually used; implementation and recurring costs are visible.
Value stateNo aggregate carries a stronger state than its least-established material component.
Failure behaviorA failed check blocks release rather than being hidden by narrative.
7. What would change the conclusion?

Every material recommendation needs a flip condition.

Examples include a firm utility commitment above the modeled requirement, a peak cooling test demonstrating materially more headroom, a confirmed water allocation below modeled demand, or wastewater chemistry that triggers pretreatment. This is how ORBIT keeps uncertainty actionable rather than burying it in caveats.

Public method boundary

Transparent enough to audit. Narrow enough to protect implementation IP.

This note describes decision logic, not patent-sensitive methods, customer data or a licensed design process. Facility-specific implementation should use the professional and authority review required by jurisdiction and scope.