Merchant Revenue Model

Assumptions

Everything the model believes, stated before the math. If you do not buy one of these, do not buy the output.

1. Atlas never forecasts a power price. Merchant revenue is historical simulation: prices are sampled from the empirical distribution of the relevant historical window, by month and hour block.
2. Observable forward curves, where they exist, enter as OBSERVED reference bands - never as Atlas predictions.
3. Only the genuinely merchant volume goes through the price bands; the contracted share is priced from the offtake record.
4. If no usable price history exists for the node, merchant revenue is UNKNOWN.

Derivation

For the project's node or hub, per-period merchant revenue is volume multiplied by prices resampled from the empirical window:

Bands are reported as P10 / P50 / P90 per period. The identification restriction is that the simulation never leaves the observed window: no trend, no drift, no view on gas, load growth or capacity margins enters the price path.

Revenue splits cleanly: contracted MW at offtake prices (from the record) plus merchant MW through the bands. The contracted share is reported so the reader can see how much of the answer is paper and how much is market.

Identification strategy

Why the estimate supports the claimed meaning - and where the model refuses to claim more than the data carries.

• Historical simulation identifies the band with the node's own realized price behavior - including its congestion and scarcity episodes - without importing a forecast model whose assumptions cannot be audited.
• The month x hour-block conditioning is what keeps seasonality and daily shape identified; pooling across blocks would average away exactly the structure merchant revenue lives on.
• Forwards are labeled OBSERVED reference bands, not Atlas views: the model reports what the market prices, badged as the market's, and never blends it into the historical band as if two different epistemic objects were one.

Inputs and outputs

Calibration and gate evidence

Validation design

• Band coverage testing: realized prices must land inside the P10-P90 band roughly 80% of the time on held-out history, per hub, before bands are shown narrow.

Evidence on record

• Coverage results per hub are not yet published in the sealed source.

Failure modes

The ways this model declines, degrades or goes UNKNOWN - and what it prints when it does.

• No usable price history for the node: merchant revenue is UNKNOWN.
• Window too short or gappy to populate month x hour-block cells: bands widen or the output is UNKNOWN; the model does not interpolate across missing cells.

Sensitivity

• The band width is the node's own volatility; congestion-prone nodes read wide because their history is wide.
• The contracted/merchant split dominates total-revenue sensitivity: a heavily contracted project barely moves with the price band.