How Our Dispatch Engine Handles Demand Spikes Without Human Intervention

The scenario plays out regularly in industrial facilities: a production line that was idled comes back online, a heat treatment cycle runs concurrently with a batch process, a compressor bank starts up. Within 30 to 90 seconds, the facility's draw from the grid increases by 15 to 25 percent above the baseline. The utility sees this as a demand event. The industrial buyer sees it as a demand charge liability. Our dispatch system sees it as a scheduled routing decision that was anticipated 400 milliseconds ago.

This piece is a technical walkthrough of how the dispatch architecture actually works, written for energy engineers and grid operators who want to understand what is happening under the hood, not a marketing summary of the output.

The Latency Problem in Grid Response

Real-time grid dispatch is not a new concept. Demand response programs, automated load control, and interruptible service agreements have existed for decades. The problem is that most of these mechanisms operate on timescales that are useful for the grid operator but not for the individual industrial buyer managing their demand profile.

A typical CAISO or PJM demand response signal has a notification period of 10 minutes to 2 hours before the dispatch event. That is appropriate for load curtailment at scale, where you are managing aggregate demand across many participants. It is not useful for a manufacturing facility trying to avoid a demand charge event driven by an internal process change that happens in the next 45 seconds.

Our dispatch system operates in a fundamentally different regime. We are not responding to grid operator signals for the purpose of serving grid needs. We are using grid price signals as one of four inputs to a routing decision that serves the industrial site's internal economics. The timescale is milliseconds, not minutes.

Four Inputs, One Decision

The dispatch engine reads four data streams continuously at a 50-millisecond sample rate:

Formation temperature. The sensor array at the wellbore bottom and at the heat exchanger inlet gives us a continuous read on available thermal output from the formation. This is not a static value. Thermal output varies with extraction rate, ambient temperature effects at shallow depth, and the natural thermal recharge profile of the formation. We maintain a rolling 15-minute average and a 5-second instantaneous read.

Grid price signal. We pull real-time locational marginal prices from the ISO market API at each sample interval. For CAISO sites, this is the 5-minute real-time LMP from the nearest pricing node. For PJM sites, similarly. The relevance of this signal to an industrial buyer is that it tells us when grid power is cheap and when it is expensive, which affects the routing decision: route geothermal output to the site load, or route it to the grid under a PPA that pays the marginal price.

Site demand forecast. We pull a demand forecast from the site's building management system or process control system, where one is available, or from our own short-horizon load model if it is not. The site forecast is the hardest of the four signals to get right. Production schedules change, equipment malfunctions, humans override the BMS. Our load model uses the past 72 hours of interval data as a prior and updates on a 5-minute basis.

Thermal output headroom. This is the difference between what the formation can currently deliver and what is currently being dispatched. It tells us how much additional output we can ramp before we hit the thermal extraction limit for this operating condition. Headroom is a function of formation temperature, current extraction rate, and fluid flow rate through the closed-loop system.

What the Dispatch Decision Actually Does

At each sample interval, the dispatch engine evaluates a routing objective: maximize economic value for the site owner given the four input signals. The objective function is not complicated. It is essentially: if site demand is about to exceed a threshold that creates a demand charge event, and we have thermal headroom, ramp output to cover the increment. If grid price is above the site's marginal cost of geothermal output, sell to the grid. Otherwise, maintain current dispatch and recharge thermal headroom.

The threshold detection for demand spike anticipation is where the architecture gets more interesting. We do not wait for the demand spike to occur. We look at the site demand forecast signal and detect the slope of demand increase in the 90-second lookahead window. If the slope exceeds a threshold that we calibrate during site commissioning, typically representing a demand increase rate that would result in a new demand peak within the billing period, the dispatch engine begins ramping output before the spike arrives.

The ramp rate of the geothermal unit is controlled by the working fluid flow rate through the heat exchanger. We can increase output from 60 percent to rated capacity in approximately 3 to 4 minutes under normal formation temperature conditions. That is fast enough to absorb most demand spikes that are foreseeable in the 90-second lookahead window. Instantaneous spikes from equipment that starts in under 10 seconds are a harder case, and we address that differently: those are typically not the demand charge events worth managing, because they are usually brief enough to average out within the 15 or 30-minute demand interval window.

Handling the Unpredictable Case

The lookahead model works well for demand increases that are predictable from the process schedule. It does not work for equipment failures that cause demand to shift, for manual operator overrides, or for production schedule changes that are not reflected in the BMS feed.

For these cases, we maintain a fast-response mode that fires on the instantaneous demand read rather than the forecast. When the 5-second instantaneous demand read crosses the site's demand set point by more than 8 percent, the dispatch engine enters fast-response mode and bypasses the forecast logic, ramping output at maximum available rate regardless of the lookahead model state. This mode has a 2-minute timeout, after which the system re-evaluates whether the sustained demand increase is a new operating baseline or an anomaly.

The practical limitation of fast-response mode is that the formation cannot be ramped faster than the thermal headroom allows. If we have been running at 95 percent of rated output already, there is limited additional headroom to deploy, and the fast-response ramp does not help much. Site commissioning includes a recommendation on normal operating point that preserves adequate headroom for fast-response events. For most industrial sites with a relatively stable baseline load, we target a normal dispatch point of 70 to 80 percent of rated output to maintain that buffer.

Grid Signal Integration: What It Actually Looks Like

We want to be precise about what "integrating grid price signals" means in practice, because there is a lot of vague language in this space.

We query the CAISO OASIS API or the PJM API directly for real-time LMP data. The latency on that data feed is typically 2 to 8 seconds behind real time, which means our dispatch decisions are made on data that is a few seconds stale. For the timescales we are operating at, that is acceptable. We are not doing sub-second arbitrage. We are making routing decisions on a 50-millisecond decision loop with data that is a few seconds stale, which means our actual decision latency end-to-end is in the range of 5 to 10 seconds from signal to routing valve actuation.

The 800-millisecond figure referenced in our site specs refers to the control path latency from dispatch decision to physical valve actuation, not to the total end-to-end latency including API data retrieval. Both numbers are real and both matter, but they describe different parts of the system.

For sites in ISO markets where the industrial buyer has access to real-time pricing rather than flat tariffs, the grid price signal integration creates a genuine economic optimization opportunity. For sites on flat-rate tariffs, the grid price signal is less useful as a dispatch input and the economic logic reverts to pure demand charge management. Both configurations are supported; the site commissioning process determines which optimization mode is active.

What We Are Still Working On

The short-horizon load forecast model is the component we are most actively improving. Our current approach using 72 hours of interval data as a prior performs well for industrial sites with highly regular production schedules. It performs less well for sites with frequent schedule changes, seasonal production variation, or significant manual override activity in the BMS. We are working on a feature that ingests production schedule data directly from the site ERP or MES system, where available, which would give us a more reliable 4-to-12-hour demand forecast. We expect that to materially improve anticipatory dispatch performance for the sites where the current load model struggles.