Technical Trust

A finding is only as useful as its basis.

Headroom v2.0 has completed its documented software verification. Separate public-data exercises checked record mapping, accounting, data quality and selected thermal calculations; they did not establish actual spare capacity at the Energy Systems Integration Facility (ESIF) of the National Laboratory of the Rockies (NLR), formerly the National Renewable Energy Laboratory (NREL). Customer-site validation and qualified external engineering review remain outstanding.

Supported methods and their boundaries

Headroom is read-only evidence software for an analyst-assisted assessment. An analyst maps supported exports; the responsible engineer confirms the equipment arrangement, conditions and assumptions. Headroom does not automatically interpret arbitrary documents or integrate with live equipment.

Natural gas: one grid connection and one already-running unit

One natural-gas engine or turbine on a common AC bus, evaluated with supplied baseline and proposal profiles. Applicable manufacturer operating points and conditions must be documented. The method does not interpolate, extrapolate or automatically derate an unprovided operating point.

Gas evidence separates pipeline delivery rate in MMBtu/hour from a finite allocation in MMBtu, both on a lower-heating-value basis. Pressure, fuel quality, protections and permitted operating periods also matter. This is not a diesel-tank model or a forecast of available runtime.

No gas-plus-battery combination, multiple units, export, startup, islanding, automatic dispatch, optimization, gas-network hydraulics or replenishment scheduling. A whole-window allocation failure does not invent a crossing time.

Grid, battery and diesel: one site, one battery, one running generator

One grid-connected site, one battery and one already-running No. 2-D petroleum diesel generator, with one isolated closed-return fuel tank. The method checks supplied baseline and request profiles, applicable limits, finite-window energy and fuel, reserves and baseline protection.

Generator net output and external auxiliaries are constant within each modeled trajectory. Site-load and battery-profile changes use explicit aligned intervals. Applicable limits and fuel-consumption evidence must be supplied.

No export, startup, islanding, refueling, multiple batteries or generators, automatic dispatch, optimization or source-specific charging attribution. A supported finite window is not repeat-cycle capability, firm capacity or permission to operate.

Cooling: bounded air, single-phase liquid or mixed arrangements

A compatible power/resource evaluation can be accompanied by one IT heat boundary, one air-removal branch, zero or one single-phase liquid branch with ordered serial interfaces, and one documented common final heat-rejection stage. Mixed cooling accounts for both paths; liquid-cooled IT may still have residual air load.

Each stage requires evidenced capacity at the applicable conditions. Baseline and proposal use the same physical chain but may have different demands, capture fractions, conditions and applicable capacities. Parallel equipment is represented only through an independently reviewed net aggregate, not automatic addition of equipment ratings.

Cooling electricity, heat removal and applicable capacity are separate quantities. Native site-load profiles must reconcile cooling electricity without double counting. Generator and battery heat must be confirmed outside the assessed cooling and rejection boundaries; otherwise the combined conclusion remains Unknown. Observed heat transfer is not a capacity rating. Shared sink allocations, uncertainty, physical limits and protected service remain explicit.

Transport, flow, fluid and temperature compatibility require supporting evidence. Latent and condensation requirements need separate confirmation. Chilled-water air handling without IT liquid capture remains air-cooled IT; it is not evidence of liquid-cooled IT.

No generic immersion or two-phase support, arbitrary rear-door or loop-network model, hydraulic or computational-fluid-dynamics simulation, rack/chip-temperature guarantee, automatic plant optimization or unrestricted campus aggregation.

Records and conditional evidence checklist

Verification record: October 19, 2026

Three evidence levels. Different conclusions.

Software verification

Tests using simulated site data check the documented software behavior, including bounded air, liquid and mixed cooling, known failures and unresolved evidence.

Public measured-data checks

Separate electrical and thermal exercises check mapping and reported quantities. Neither establishes actual ESIF spare capacity or a complete electrical-and-thermal capacity conclusion.

Customer and engineering validation

An authorized real-site package, qualified external engineer review and evidence of operator usefulness remain outstanding. Software acceptance does not close those milestones.

Recorded software verification, integrity and replay results

The final benchmark used the unchanged, previously verified product implementation; its records closeout did not change the software.

Different, overlapping sets. No cumulative test total.
Set	Recorded result	What it establishes
Product acceptance	1,991 tests passed	Previously recorded full successor acceptance, reused for unchanged product source. Not a fresh full-suite run for the final benchmark.
Affected source tests	129 tests passed	Fresh benchmark and affected-regression checks in the source environment.
Extracted environment	129 tests passed	The overlapping affected tests in the extracted environment, not another independent acceptance suite.
Output reproduction	8 files byte-identical	Recorded observed-result files regenerated exactly; not proof of physical measurement accuracy.
Selected bundle replay	13 replays passed	Selected reproducibility checks, not 13 real-site validations.
New archive integrity	358 hashes matched	File integrity against the recorded manifest, not permission to redistribute restricted materials.

These counts overlap and are not additive. Matching files and repeatable results do not establish measurement accuracy, engineering approval or customer validation. The 1,991-test acceptance applies to the unchanged product implementation; the later benchmark checks are separately identified above.

What the public-data exercises establish

Electrical records

A bounded ESIF electrical-records exercise checks mapping, consumption and PUE accounting, data qualification and replay. It does not establish installed-site spare capacity.

Published electrical-data reference (NLR)

Thermal records

A separate exercise covers positional mapping, temperature differences and reported-heat arithmetic across 1,225 observations from an incomplete September 1, 2016 sample. Missing periods were not imputed or replaced.

It does not independently establish flow, fluid properties, instrument accuracy, capacity ratings, sink allocations or a matching electrical model. The two exercises are not a combined site-capacity validation.

The capacity examples use separate synthetic systems, not actual ESIF equipment, limits or operating assumptions. No endorsement, certification, development participation or customer relationship involving the U.S. Department of Energy or the National Laboratory of the Rockies is implied. Thermal-data reuse questions remain unresolved. The public findings do not include the underlying thermal dataset.

How to read a result

Supported: The required checks support the supplied finite scenario within its documented conditions, without granting operating authorization.
Not supported: A known constraint prevents support, even when other checks pass or evidence is missing.
Unknown: Required evidence does not establish a conclusion.
Not evaluated: The assessment was not performed for this question or domain.

Unknown does not mean zero physical capacity.

Power/resource, thermal and overall conclusions are reported separately. Diligence priorities and intake readiness are separate from capacity findings.

Verification record: October 4, 2026

Software checks, not site validation.

The October 4 records cover the standalone generator/fuel model and its extracted review package. They are retained as an earlier verification record, separate from the October 11 combined Stage 4 checks below.

This earlier entry describes the scope of that work rather than listing test counts. It is not a fresh verification of the combined engine.

The generator demonstration covers one already-running, grid-connected diesel generator, isolated No. 2-D fuel inventory, and supplied constant baseline and request profiles. It excludes startup, refueling, optimization, battery combinations, and equipment control.

Purpose and inputs

Does 400 kW of additional load fit a 3-hour window?

One grid-connected site, one battery and one already-running diesel generator. October 1, 2026, 00:00–03:00 UTC.

Finding

Not supported.

Generator power constraint

The supplied generator output exceeds its scenario rating at the start of the modeled window. The baseline passes; the supplied request does not.

Supplied gross output: 550 AC kW
Scenario limit: 500 AC kW
Power margin: −50 AC kW

Basis

400 kW describes the extra site load. The generator profile is separately supplied: 530 kW net + 20 kW external auxiliaries = 550 AC kW gross.

Trace the request through the supplied profiles

The 400 kW request is additional site load, not the generator output. The retained request profile separately supplies 530 AC kW of net generator output and 220 AC kW of battery discharge. Headroom checks that supplied combination; it does not choose or optimize it.

Case T / Constant profiles for October 1, 2026, 00:00–03:00 UTC. Power values in AC kW.
Power balance	Baseline	Request
Existing site load	1,200	1,200
Additional site load	0	400
Battery discharge	20	220
Generator net output	180	530
Calculated grid import	1,000	850
Generator external auxiliaries	20	20
Generator gross output	200	550

Site balance: 1,200 + 400 = 850 + 530 + 220 AC kW.

Battery charging is zero in both supplied profiles. The request changes the assumed source mix: compared with baseline, generator net output rises by 350 kW and battery discharge by 200 kW, while calculated grid import falls by 150 kW. Together these changes serve the additional 400 kW in the modeled balance.

Generator rating check: 530 + 20 = 550 AC kW gross.
Power margin: 500 − 550 = −50 AC kW.

The supplied applicable continuous rating is 500 AC kW gross, before external auxiliaries. The generator constraint fails at October 1, 2026, 00:00 UTC, the start of the modeled window. These are synthetic profile and rating inputs, not verified equipment measurements. The retained baseline passes its required checks; the proposal fails the generator rating at the start.

Other findings

Fuel protection also fails.

The supplied fuel consumption is 140 L/hour, from an initial 500 L. Hypothetical fuel after three hours is 500 − 140 × 3 = 80 L. The physical floor is 50 L and protected reserve is 50 L: a combined 100 L threshold. Fuel reaches that threshold at (500 − 100) / 140 × 60 = 171.43 minutes (approximately), and falls below it strictly afterward.

Baseline protection also fails.

The baseline consumes 60 L/hour. At elapsed time t in hours, the request must retain 100 + 60 × (3 − t) L for the floor, reserve and remaining baseline need. Its margin is (500 − 140t) − [100 + 60(3 − t)] = 220 − 80t L. The margin reaches zero at 2.75 hours (165 minutes), fails strictly afterward and is −20 L at the three-hour endpoint.

Power fails at time zero. All later fuel arithmetic is hypothetical continuation of the rejected profile, not observed depletion or a supported operating period. The 165-minute and 171.43-minute thresholds do not establish a safe shorter request.

Next step

Review the supplied generator profile, rating, auxiliaries, fuel-consumption evidence and protection requirements with the site engineer. Agree any revised inputs before rerunning the analysis.

Reducing the requested load by 50 kW is not established as a passing alternative. The other failures remain, and no replacement profile has been evaluated.

Download Case T inputs, margins and findings. This public extract includes selected inputs and calculations, not the complete replay package. It identifies the retained October 11, 2026 synthetic result.

Synthetic example. Not a customer result. This is not physical validation, operating authorization or proof of production readiness. Supplied profiles, not measured performance. A finite-window result does not establish repeat-cycle or firm capacity.

Verification record: October 11, 2026

Combined Stage 4 software verification

The retained final-revision logs report the checks below. These are originating-run internal software checks on simulated cases, not external engineering approval or real-site validation. These dated checks describe that retained implementation, not a new acceptance run.

October 11, 2026 test counts, provenance and replay checks

Suite	Recorded result	Scope
Stage 4-only	68 tests passed	Combined-result aggregation, required-check coverage and result semantics.
Combined targeted suites	756 tests passed	Targeted checks across the combined stages, including Stage 4.
Full explicit-successor suite	1,447 tests passed	The complete repository successor run; no failures, errors, skips, deselections or expected-failure exemptions.
Historical regressions	28 tests passed	Preserved regression checks against the corrected successor behavior.
Extracted compact package	694 tests passed	Tests run from the extracted review package in a fresh, pinned environment; not the full repository suite.

These sets overlap and are not additive. Do not sum them into a total or treat them as independent approvals.

Package checks also verified 482 artifact hashes and exact membership, seven stage replay commands, and eight tamper-rejection probes. Fresh generation reproduced 68 Stage 4 artifact byte strings: 32 JSON reports, 32 Markdown reports and four supporting files. These are artifact checks, not additional test-suite counts.

The result applies to the modeled inputs and finite window. Software reproducibility and matching hashes do not establish the accuracy of equipment records, customer validation or permission to operate a site.

Historical standalone battery example / August 1, 2026 / 300 AC kW

Separate historical synthetic test

Synthetic example. Not a customer result.

Grid supply, charging and discharge are different contributions.

Purpose: test one fixed grid/battery profile for 300 AC kW of additional load from August 1, 2026, 12:00–15:00 UTC. The retained result supports that finite profile; it is not evidence that the battery alone supplies 900 kWh.

Inputs: existing site load is 400, 900 and 900 AC kW in the three one-hour intervals. Battery charging is fixed at 200, 0 and 0 AC kW. Charge efficiency is 90%, discharge efficiency is 80%, and DC auxiliary demand is zero.

Proposal trajectory / one-hour intervals, August 1, 2026 UTC
Interval	Grid import, AC kW	Battery charge / discharge, AC kW	Ending stored energy, DC kWh
12:00–13:00	900	200 / 0	780
13:00–14:00	1,000	0 / 200	530
14:00–15:00	1,000	0 / 200	280

Electrical balance: hour one uses 400 + 300 + 200 = 900 AC kW from the grid, including charging. Each later hour uses 900 + 300 = 1,000 grid + 200 battery AC kW. Baseline grid imports are 600, 900 and 900 AC kW; compared with baseline, the additional load receives 300 + 100 + 100 = 500 AC kWh from increased grid import and 200 + 200 = 400 AC kWh from battery discharge.

Stored-energy calculation: 600 + (200 × 0.9 × 1) − (200 / 0.8 × 2) = 280 DC kWh. Charging adds 180 DC kWh from 200 AC kWh; later discharge withdraws 500 DC kWh to supply 400 AC kWh. The corresponding conversion losses are 20 kWh on charging and 100 kWh on discharge. The net stored-energy decline is 320 DC kWh, not the additional load's 900 AC kWh.

Finding: both baseline and proposal pass the retained fixed-profile test. Baseline stored energy ends at 780 DC kWh; proposal ends at 280 DC kWh. This is a standalone grid/battery example with no generator or cooling evaluation. It does not establish repeat-cycle capability, firm capacity, measured equipment performance or engineering approval.

Retained source identification

Historical fixed-profile battery-replenishment input and result, synthetic window August 1, 2026; source analysis date August 2, 2026. These are retained synthetic records, not new tests or measured site evidence.

Earlier standalone generator and fuel examples / simulated data

Synthetic engineering demonstration

Synthetic example. Not a customer result.

Generator and fuel-duration examples

Example site. The boundary is one already-running, grid-connected diesel generator, an isolated No. 2-D fuel inventory, and supplied constant baseline and request profiles. Each case below is a separate simulation, not a stage of one run.

Three-hour request: The request fits the case assumptions; fuel falls from 400 L to the 100 L endpoint reserve. The 100 L endpoint is the physical floor plus protected reserve. No support beyond that endpoint is implied.
Priority protection: A separate priority-protection case binds at 105 minutes. Fuel needed for higher-priority obligations is protected before physical depletion.
Protected reserve: A separate protected-reserve case binds at 120 minutes. The priority reservation binds first; the static reserve would bind at 156 minutes in hypothetical continuation.
Fuel uncertainty: The uncertain-fuel case is bounded at 142.5 minutes. This is the conservative priority bound under the supplied inventory and consumption uncertainty, not observed depletion.
Power envelope: A 550 kW request exceeds the 500 kW generator envelope. Adequate modeled fuel does not override the electrical power limit.
Missing consumption evidence: Missing fuel-consumption evidence returns Unknown, not zero. Fuel quantities and full support remain Unknown; independently known electrical limits can still be reported.

These synthetic engineering demonstrations are not customer results, physical validation, operating authorization, or proof of production readiness. They do not include startup, refueling, optimization, battery combinations, or equipment control. They are not a combined grid, battery, and generator calculation.

Read the October 4, 2026 verification summary.

One site. One question. An agreed period.

First Site Evaluation

A scoped assessment using Headroom software for one site and one decision. Start with a short fit discussion; suitable records and a supported question are required. Agree scope, written authorization and data handling before sharing records.

Written finding within five business days after scope is agreed and the required records are confirmed.

Request a First Site Evaluation

Review the records checklist and who develops Headroom. No sensitive records are needed for the initial inquiry.

Current scope and important limits

Evidence for a supplied proposal

Headroom v2.0 is read-only, export-based and analyst-assisted. It checks a supplied proposal over a stated period; it does not operate equipment, request control credentials or automatically ingest arbitrary documents.

A supported result depends on the supplied evidence and applicable method. Unknown does not mean zero capacity. No maximum-MW, safe shorter duration, repeat-cycle, firm-capacity or revenue guarantee is implied.

Separate methods, bounded combinations

Natural-gas and grid/battery/diesel evaluations are separate methods. Bounded air, single-phase liquid or mixed cooling can accompany a compatible evaluation. Gas-plus-battery, multiple generating units, startup, islanding and automatic dispatch are outside the supported scope.

Internal software tests and bounded public measured-data checks are complete. Separate public-data exercises checked record mapping, accounting, data quality and selected thermal calculations; they did not establish actual ESIF spare capacity. Customer-site validation and qualified external engineering review remain outstanding. Read the method boundaries.