How aggregated bid curves are captured and replayed
The aggregated supply and demand curves are the closest thing to an order book that European day-ahead auctions publish. Most exchanges serve them for about a day and then stop answering, so reading one for last Tuesday depends entirely on whether a capture ran.
What the screen answers
For one market area, one auction and one delivery period: what the aggregated supply and demand curves looked like, where they crossed, and how steep the book was around that crossing.
This is the published book rather than a reconstruction. Where it and the merit-order view disagree about how steep an hour was, believe this one - it has no model error, because there is no model.
Where a curve comes from, and what the badge means
Every rendered day carries a badge, and it is not decoration: it decides how much of the curve you are actually looking at.
- Live
- Read from the exchange at request time. One area's own exchange answers any past delivery date, so nothing is captured for it and every visit reads live.
- Archived
- Replayed in full from the raw payload we stored while the exchange was still serving it. This is the complete curve, identical to what live would have returned that day.
- Derived
- The prices and volumes we extracted at capture time, without the raw payload behind them. You get the shape and the crossing, not every step.
A derived day states which of its two causes applies: the payload was never archived, or it was archived and this deployment cannot reach the archive - in which case nothing is lost and two environment variables fix it. Those are different problems and the page never collapses them.
Why a delivery day can be refused
Most areas publish only the current and next delivery day, and return an authentication error for anything older rather than an empty result. So a delivery day exists here only where the capture ran.
Asking for a day outside that set is not a failure and is not reported as one: the page says the day was requested, is not in this auction's archive, names the range of stored days that do exist, and shows the nearest one instead. A capture that has never run for an auction says that too, rather than showing an empty range.
Reading the chart
- Supply and demand
- Cumulative volume on the x axis, price on the y. Supply rises, demand falls, and the crossing is the clearing point the auction published.
- The steepness at the crossing
- How much price moves per unit of volume where the two meet. A steep crossing is where a small change in offered volume moves the clearing price a lot, which is the condition that makes withholding worth screening for.
- The day sparkline
- The same area and auction across the whole delivery day, so a period can be placed against the shape of the day before it is read closely.
- The tables
- Every step behind the drawn curve. They are the chart's text alternative, and the place to read exact volumes at exact prices.
What an aggregated curve cannot show
It is aggregated. Individual orders are not in it, block orders cannot be represented in it, and no participant identity is attached to any step. A step that carried the volume setting the price can be pointed at; whose step it was cannot.
It also covers whatever the publisher aggregates over. Where an exchange publishes one merged book for every zone clearing at the same price, the curve is that whole group's, not one zone's - and a delivery period where a zone was congested off the group carries its own book instead.