Skip to main content
Reality Oracle
OverviewCitizensReality FeedVerified ActorsIntel SubscribersMarket PredictionInvestment FundsHow It WorksGates
Products
Backtest ForensicsLiving MapDrift AlertsPath QueriesCustom AxesRisk Maps
Solutions
Compliance OfficersRisk Managers / CROPortfolio ManagersCTOs & Engineering
Enterprise
Enterprise OverviewReality Oracle · SuperappThe AppsArchitectureAudit ManifestTrust CenterPricing
Developers
DocumentationAPI ReferenceSDKsArchitectureAudit Manifest
Resources
BlogUse CasesCustomer StoriesPressChangelog
Company
AboutFoundersCareersContact
Trust
Trust Center
More
PricingJoin Waitlist
··12 min read

An energy utility forecasts load as a cone

Peak-load distribution for a grid that hedges. Anonymized, illustrative.

An energy utility forecasts load as a cone

A peak-load number is a bet the grid cannot hedge. A peak-load cone is a shape the grid can hedge, because the tail is in the shape, not outside it.

This is an anonymized design-partner scenario; the institution is an energy utility, the figures are illustrative, and no actor has agreed to anything. We are pre-revenue, building the POC. With that label on it, here is what peak-load forecasting looks like when the deliverable is a cone the grid can hedge, not a number the grid has to trust.

Peak load as a distribution

A utility that says "peak load will be 18 GW" has handed the grid operator a point estimate — a single number with no hedge. A peak-load cone replaces the number with a distribution: the central scenario, the high-demand tail, the entropy. The grid operator reads the tail to size reserves, reads the entropy to know whether the model agrees with itself, and reads the modes to know whether there are two weather regimes. The shape is the deliverable; the number was a collapse of it.

Illustrative. A peak-load cone: the central path is the base case, the upper tail is the reserve contingency, the entropy is the honesty the operator reads to size the hedge.
Illustrative. A peak-load cone: the central path is the base case, the upper tail is the reserve contingency, the entropy is the honesty the operator reads to size the hedge.

The tail is the hedge

A grid hedges the tail, not the central path. The point estimate hid the tail; the cone shows it. The Oracle normalizes the Ensemble in one place: probabilities sum to one, scenarios sorted descending, entropy in nats. The high-demand tail is a scenario with a probability, not a footnote; the reserve sizing is read from the tail, and the cost of the reserve is read from the probability. The cone is the shape that makes the hedge a number, not a guess.

A grid hedges the tail, not the central path. The point estimate hid the tail; the cone shows it — and the hedge becomes a number, not a guess.

  • Peak load as a distribution: central path, high-demand tail, entropy — the shape a grid operator reads.
  • The tail is the hedge: reserve sizing from the tail, reserve cost from the probability.
  • Entropy in nats: the honesty field that says how spread the model doubt is across weather regimes.

The manifest the regulator can replay

A load cone that cannot be replayed is a chart, not an artifact. The manifest records the NodeVersions — the weather data, the demand history, the plant outages — so the cone is reproducible bit-for-bit. A regulator asking "how did you forecast peak load?" gets the manifest, not a slide. The utility does not get a certificate that the peak-load forecast was correct; they get a reproducible record of how the cone was produced, and the calibration loop (Gate 1b) is what would earn the probabilities on it. Not passed; the loop is in motion.

A peak-load number is a bet the grid cannot hedge. A peak-load cone is a shape the grid can hedge, because the tail is in the shape — and the hedge is read from the tail, not guessed from the point.

— design-partner grid note
§Keep reading