Dashboard forecasts the first ~24h against a day-ahead auction that already cleared

[ducroq]

What

t0 is the last hour of today local (e.g. 2026-09-05T21:00Z, run generated 16:31Z). So forecast hours 1–24 are the next delivery day — and the NL day-ahead auction clears those prices at ~12:45 CET, roughly four hours before the nightly run starts.

The dashboard already has the real numbers: static/js/modules/api-client.js:226 fetches Energy Zero for today, tomorrow and the day after. But static/js/modules/data-processor.js:256 draws the forecast line across every timestamp >= cutoffTime, not just future ones. Net effect: the chart plots a ~27 EUR/MWh error (measured 1–24h MAE) on top of the correct answer sitting in the adjacent trace.

The band is already restricted to future hours (futureTs filter); the line is not.

Why this matters beyond cosmetics

It removes a third of the forecast horizon from the "does this add value?" question. Only 25–72h is genuinely predictive — and there the model is 4–5 EUR/MWh behind seasonal-naive (see #29).

Not yet decided — needs its own pre-commitment

Two things to settle before building anything:

1. Does EDH's file already carry tomorrow's cleared prices? The consolidated parquet stops at end-of-today-local, and t0_held_back_hours was 0.0 on 2026-09-05, so price_t0 genuinely ended there. But wait_for_edh.sh's own contract suggests a normal entsoe publish holds two days (the 2026-09-04 incident refused a publish with "same-day prices only, 96 vs 192"). If the data is already present, this is a consolidate/anchor change; if not, it needs a fetch. Unverifiable on the dev box — no decryption keys there. Check on sadalsuud.
2. What should the chart show for those hours? Published price only, or published price and forecast (as an honest visible accuracy check)? The second has some diagnostic value and no product value.

Scope note

This is a product change, not a model finding. It does not affect any pre-committed experiment, and it should not be bundled with the model-class work in #15 / #29.

Related: #29, #18 (wholesale vs consumer labelling touches the same traces), #24 (dashboard hardening)

[ducroq]

Clarified 2026-09-11 — the forecasting of these hours is deliberate, and this issue was framed as though it were not.

The 1–24h block is forecast on purpose. At run time the day-ahead prices for those hours are already published, so the pipeline can be scored against ground truth immediately, without waiting a day for realisation. That is the only zero-latency check this system has.

Recording it because this issue, CLAUDE.md and the hypothesis-log Step 3 all filed it as an open product question blocked on whether EDH's file carries tomorrow — and it was argued the wrong way in session today. "Stop forecasting hours you already know" is a reasonable-sounding move that removes the instrument.

⚠️ But EXP-037 measured how badly this block flatters. It is the one place the model still holds diurnal shape:

within-block forecast spread, EUR/MWh
                    h1-24   h25-48   h49-72
realised            42.29    42.54    42.69
carry               41.13    41.13    41.13
lgbm_full p50       26.57    14.32    14.94

And on cost regret it beats the carry at 1–24h (+0.84 EUR/MWh) while losing heavily beyond it (−3.85, −5.94).

So a self-test on this block passes while the hours the product depends on degrade — flattering by roughly a factor of two in amplitude and by a sign flip in regret. Use it as an integrity check ("did the pipeline produce sane output tonight?"), never as a health proxy for 25–72h. If it is to serve as the health check it should be stratified per horizon group; ml/shadow/exp037_rank_metric/summary.json carries the per-block baselines to calibrate against.

What remains open here, narrowed: whether the dashboard should display the published prices for those hours rather than the forecast. Displaying published prices and forecasting them internally are independent choices — api-client.js loadEnergyZeroData() already fetches today, tomorrow and day-after-tomorrow, so the client-side data is present regardless. Still undecided, and it needs the wholesale-vs-consumer question in #18 settled first.

[ducroq]

The premise of this issue stopped holding in production on 2026-09-13 — by accident, and it can revert the same way. See #34.

The EDH gate had settled into consuming the previous day's publish, so t0 was <run date> 21:00Z. That is what made h=1..24 cover a day whose auction had already cleared at the moment the forecast was published — the "zero-latency self-test" this issue describes. On 2026-09-13 the lag broke and t0 became <run date +1> 21:00Z, so h=1..24 now covers a day whose auction clears roughly 16h after the forecast is published. The block this issue is about is currently gone.

Two consequences for this issue:

1. The self-test is not a property of the design. It was a property of a lag nobody had noticed, and nothing holds it in place — the next EDH multi-publish day re-seeds the lag and it returns, silently, with no alarm (the t0 guard checks the delta, which a uniformly-lagged pipeline satisfies exactly). So "deliberate, it is the zero-latency self-test" — as recorded in CLAUDE.md — was not accurate about why the block existed, though it was accurate that the block was useful.

2. Which way to resolve it is now coupled to EDH gate has no freshness test, so it settles into a one-day lag — and breaking that lag moved the forecast anchor 24h #34. Ratifying lag-0 removes the block permanently and settles the dashboard half of this issue by construction. Restoring the D-anchor keeps it, but then it has to be an explicit one-publish offset rather than an accident. EXP-037's finding — that the h=1..24 block flatters the scores, so horizons must be stratified before that region is trusted — argues for ratifying lag-0 and closing this, but that is the call to make in EDH gate has no freshness test, so it settles into a one-day lag — and breaking that lag moved the forecast anchor 24h #34, not here.

The separate question this issue also raises — whether the dashboard should render published prices rather than a forecast wherever the auction has cleared — is unaffected by any of the above and stays open on its own merits.

[ducroq]

Resolved on the model side by #34, ratified 2026-09-14 — and this issue's own evidence is what decided it.

api-client.js:227 already fetches today + tomorrow + day-after from Energy Zero every 10 minutes, and data-processor.js:256 was drawing the forecast line over them. That is the whole of this issue's complaint, and it made the choice in #34 easy: the D-anchor was spending a third of the forecast's horizon budget restating an auction the page already had. lag-0 is now ratified and the gate's clause (c) holds it there, so the block is gone and — unlike last week — it cannot come back silently.

Since 2026-09-13, h=1..24 covers a day whose auction clears roughly 16h after the forecast is published. ⚠️ Stratify per horizon before trusting any score from that region dated earlier than 2026-09-13, because under the old anchor it was a restatement and EXP-037 showed it flatters.

What remains open here is the narrower, genuinely separate question this issue also raises: should the dashboard render published prices wherever the auction has cleared, rather than leaving the gap to the live Energy Zero fetch? That is a product decision about how the two series are drawn together, and nothing in #34 settles it. Leaving this open for that alone; the "we forecast 24h we do not need to" half is closed.