When to publish nothing

There are three ways a live forecast dashboard can mislead you. It can show yesterday's number with today's timestamp. It can show nothing where there should be a number. Or it can show a number that looks plausible and is wrong. Most of the engineering time we spend on the live dashboard goes into making sure the second failure mode wins over the other two.

The march anomaly post covered the model-side response, instance-time renormalization to keep the backbone in distribution when load regimes shift. This post is about the other half: the operational guardrails that decide what a customer is actually allowed to see. None of it is glamorous. All of it matters more than the choice of architecture.

Plausibility bounds, per ISO

The first guardrail is a hard plausibility filter on every forecast value before it reaches the chart. We maintain a per-ISO band tuned around each grid's historical operating envelope. Anything outside is dropped before rendering, regardless of how the model arrived at it.

These bounds are not tight. A correct forecast will sit deep inside the band every time. The point is not to second-guess the model on close calls; it is to catch sign-flipped values, missing-decimal artifacts, and the kind of corrupt outputs a model can produce when its inputs go subtly wrong upstream. A forecast of negative load is not a forecast we want a trader to act on, even for a fraction of a second.

The filter runs at query time, not at write time. We considered scrubbing values during ingest, but that loses information, when the model produces an implausible value, that itself is signal worth keeping. So the raw forecast table accumulates everything, and the dashboard read path filters at the edge. When the filter rejects values, we count them and surface the count in the warming-up message: “filtered N implausible points.” If N is large, the on-call rotation gets paged.

The warming-up state

When too few valid forecast hours survive the plausibility filter for a given grid, the chart switches into a state we call warming up. The actual load line still renders, operators need that situational awareness even during a forecast lag. The forecast line does not. The chart header shows the time of the most recent successful model run and a note that the pipeline refreshes shortly.

Below the threshold, we publish nothing. We do not publish a partial line that visually implies continuity where the data is missing. We do not interpolate over gaps. And we do not let the chart render a confident curve from a handful of valid points stretched across the window. A trader looking at a forecast line is making a decision; a forecast line that is mostly imagination is worse than a line that is absent.

The warming-up state is the most visible application of a principle we apply everywhere in the read path: silence on uncertainty, never confident fabrication. The cost of a five-minute gap in the chart is real but bounded. The cost of a chart that looks normal while reporting a fabricated trajectory is open-ended.

On the morning of March 17, our pipeline showed CAISO “warming up” for eighteen minutes during the hour-ahead window of the heat event. A trader running on our feed did not see a confident bad number; they saw nothing, and either held position or reverted to their fallback. That is the trade we want to enable: act on a number you can stand behind, or do not act on this number. Eighteen minutes of silence beats eighteen minutes of confident wrong.

Freshness as a first-class signal

The third rule: every published value carries a timestamp, and that timestamp is rendered on the page. The home dashboard surfaces a freshness strip with one tile per ISO showing the most recent forecast issue time as a relative age , “3m ago,” “1.4h ago,” never “recent.” The forecast comparison page shows the model run time in the chart header. The usage page shows the last successful poll time in the corner. Every number on every screen is timestamped.

That sounds obvious until you watch a dashboard fail silently. Polls fail. Caches stale. Connections drop. A user who sees the same number three times in a row, with no indication of when it was last refreshed, has no way to know whether the system is healthy or has been frozen since their last cup of coffee. The cure is to make age explicit: timestamp every value, color-code staleness, and force the dashboard to admit when its data is older than it should be.

We use UTC for all operational timestamps. Local time has its place, the greeting on the dashboard home page can say “good morning” in whatever zone makes sense, but data timestamps belong in a single, unambiguous reference frame. Energy traders work across multiple time zones and ISOs, and most of them already think in UTC for the same reason. We meet them there.

The boring half of accuracy

None of this is what an accuracy benchmark measures. MAPE does not penalize a forecast for being stale. It does not reward a system for refusing to publish during a regime shift. It does not distinguish a value that survived a plausibility filter from one that should not have left the model. Accuracy benchmarks measure the forecast at its best.

Customers experience the forecast at its worst. The day a pipeline degrades, the hour an ISO publishes garbled telemetry, the minute a model run fails to complete, those are the moments where the value of a forecast service is decided. A 2% MAPE provider whose dashboard publishes corrupt values during a pipeline incident is, in operational terms, less useful than a 3% MAPE provider whose dashboard goes quiet and tells you why.

The march 2026 anomaly was one kind of failure, a regime the model could not anticipate. The fix for that was architectural. The failures we have not yet had, a sensor going offline at the wrong moment, a model run timing out during a heat event, a forecast produced from inputs that were themselves stale, call for a different kind of engineering. They call for a dashboard that, faced with a question it cannot answer well, prefers silence to a confident wrong number. That is what we have been building, and it is what we will keep building.