FATHOM Dispatch. The optimiser that decides what your asset does next.

FATHOM Dispatch is where the money is made and lost. The lane formulates the operator's problem as a rolling-horizon mixed-integer stochastic programme over a 4-hour to 168-hour horizon, re-solved at the customer-chosen cadence — typically every five minutes, sometimes faster on event triggers. The objective is portfolio P&L net of asset-degradation cost. The constraints encode the physics, the contracts, and the network: per-asset ramp and energy limits, per-cell cycle-life budgets, per-feeder network capacity envelopes, per-product contracted obligations, and per-portfolio reserve commitments.

The decision variables are continuous power set-points per asset per settlement period, plus binary commitment for products with on/off discontinuities. The output is a set-point trajectory, a probability of constraint binding at each percentile of the forecast distribution, and a structured rationale that explains why a particular set-point was chosen — not just what it is. That rationale is the thing that survives the post-trade review with the trading desk and the post-incident review with the regulator.

The lane is co-optimisation in the literal sense. We do not run wholesale first, then run DC-L on the residual, then bolt capacity-market obligations on top. We solve all of them jointly, which means the optimiser can choose to give up a wholesale trade because the cycle it would consume is more valuable held as headroom for a likely frequency event two hours later. This is the single biggest revenue-uplift our customers see versus their incumbent stacks.

Every battery vendor promises stacked revenue. Most operators leave 25–40% on the table because the naive stacking strategy — wholesale first, then frequency response on whatever capacity is left over, then capacity market on top — does not survive contact with reality. Frequency-response commitments constrain the state-of-charge envelope; capacity-market obligations constrain the binary "available" state; wholesale opportunities are stochastic and time-correlated with the very events that move the frequency response market. The four stacks fight, and the operator who does not solve them jointly is leaving 14.2% of revenue on the table on average across our fleet.

FATHOM Dispatch's conflict-resolution rules are explicit and operator-controllable: capacity obligations are hard (we will not breach them); frequency-response commitments are soft-hard (we will not breach without operator approval but the lane can recommend a buy-out); wholesale is soft (we will give it up if the joint value is lower); ancillary services like reactive support sit between, with per-portfolio rules. The operator can override any layer through the structured intervention API, and every override lands in the same audit ledger as the optimiser's own decisions.

Across eight live UK assets we measure a mean revenue uplift of 14.2% versus a strong rules-based baseline, sustained over twelve months. The figure is calibrated against a control window (months where the lane was deliberately switched off for one asset at a time) and against a counterfactual model that replays the period with each asset's incumbent stack — both methods give numbers within 0.6% of each other.

Every decision emitted by FATHOM Dispatch lands in an immutable audit ledger before it touches an actuator. The ledger entry carries the solver instance hash, the forecast band the decision was made against, the model and warm-start versions, the binding constraints, the marginal value of every product, and a signed receipt from the EMS confirming actuator state. A regulator who wants to know why a particular set-point was emitted at 14:22:33 can resolve the answer in under three seconds. We built this because the question gets asked, and because "we will get back to you" is not an acceptable answer when the question is from Ofgem.

Operationally the lane is meant to disappear. Hot-standby on two nodes per region; sub-second failover with zero loss of dispatch state; rolling upgrades that interleave with the five-minute solve cycle so the new binary takes over only after it has shadowed the incumbent for three full solves. The default deployment expects two GPUs per region and one CPU-only edge box per substation; smaller deployments collapse the warm-start net and the solver onto the same node and lose roughly 8% of P99 latency in exchange for a smaller bill of materials.