TARIFF-14: the point whose own interval covers the instant

`_Series.at()` asked `s <= u < s + 1 h` of every point IN LIST ORDER and returned the FIRST match. On the hourly shape every fixture in this repository carried before TARIFF-08 that is right by accident. Belgium moved to a 15-minute MTU on 2025-10-01 and the live day-ahead feed returns 96 points at 900 s, where it is wrong twice over - measured against the shipped code at 5059e28: series: 02:00=0.10 02:15=0.11 02:30=0.12 02:45=0.13 03:00=0.14 ask +15min -> 02:00 0.10 <-- WRONG (wanted 02:15) ask +60min -> 02:15 0.11 <-- WRONG (wanted 03:00) ask +75min -> 02:30 0.12 <-- WRONG (wanted 03:15) Inside the first hour the :00 point wins because its hour has not run out. From the second hour on the answer is not even the top of the hour - the first point still inside its own hour wins - so the error compounds with depth into the series. `arbitrage._act()` tests `here.start == v.cheapest.start` / `== v.dearest.start` to decide whether this interval is the buy one or the sell one. That identity almost never held, so the strategy idled through exactly the interval it exists to trade, and read §8.3's `here.provisional` and §17's `price < 0` off the same wrong point. `static_tariff.py` emits hourly points, so static sites were never affected; this is reachable only down the dynamic path TARIFF-08/09 made work. THE RULE: a point covers from its own start until the next point's start, and never more than one hour. Quarter-hourly takes 900 s, hourly is unchanged, and a MIXED series - FCST-04's carry-forward puts hourly carried points beside quarter-hourly firm ones, spacing [900, 3600] in 70 % of soak samples - takes each point's OWN gap. The one-hour cap is load-bearing: FCST-04 leaves an hour OUT when nothing published it and yesterday has no value, and `at()` raising Absence for it is what sends the caller to the static profile (§11.4). Uncapped, "until the next point's start" would stretch the point before a three-hour hole across the whole hole and answer every instant in it with a stale price. THE LAST POINT is given the same span as the point before it (one hour when it is the only point). A flat one-hour tail would answer 00:30 TOMORROW with today's 23:45 price. The cost - a mixed series ending at the firm/carried seam loses its last 45 minutes to Absence - is argued in DECISIONS/TARIFF-14-the-window-a-point-covers.md §2 rather than buried; the direction is the safe one. `at()` now reads a point's NEIGHBOURS, so it would depend on sortedness. It establishes that itself: the lookup index is sorted by UTC start once, at construction, so no caller's list order reaches it. A series handed its 96 points in reverse answers identically, and that is a check. `covers()` shared the defect exactly - it has no rule of its own, it asks `at()` - and is fixed by the same change; `window()` did not, and its docstring now says why. Nothing about §9.3 or a point's `start` changed. PricePoint still has three fields; the span is derived from the neighbours, never stored. Graded by test_price.py section 13 (900 s, 3600 s, mixed, holes, the tail, caller order, duplicate starts, covers()/window(), the no-data contract) and end to end by test_arbitrage.py section 10, which drives decide() over a 96-point quarter-hourly day whose cheapest and dearest quarters are deliberately NOT on a whole hour, plus §17, §8.3 and the mixed series. Eight mutations, all red, including a ZERO-BYTE one on the tail rule; byte deltas and what the arbitrage file could not see are in the decision note §6. All 29 test files green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU
2026-09-12 21:22:28 +02:00
parent 88c59a9918
commit 7f2c4e20e1
5 changed files with 1142 additions and 9 deletions
@@ -17,6 +17,91 @@ if it has, it needs 0.10.0. Whoever deploys decides.
 | _this branch_ | FCST-06 - "cannot persist" stops meaning "has no /data" and starts meaning what it says |
 | _this branch_ | TARIFF-08 - the day-ahead feed is read in the shape it actually publishes, and the fixtures stop agreeing with the parser |
 | _this branch_ | TARIFF-09 - the day-ahead feed is asked for the horizon it was given, so tomorrow arrives firm instead of carried |
+| _this branch_ | TARIFF-14 - the price a trade is decided against is the price of the interval being traded |
+
+### TARIFF-14 - the trade was decided against the wrong price
+
+**On the only price feed that works, `_Series.at()` returned the wrong point,
+and the error grew with depth into the series.** It asked
+`s <= u < s + 1 h` of every point **in list order** and returned the **first**
+match. On the hourly shape every fixture in this repository carried before
+TARIFF-08 that is right by accident; Belgium moved to a **15-minute MTU on
+2025-10-01** and the live day-ahead feed returns **96 points at 900 s**, where
+it is wrong twice over. Measured against the shipped code at `5059e28`:
+
+```
+series: 02:00=0.10  02:15=0.11  02:30=0.12  02:45=0.13  03:00=0.14 ...
+
+ask + 0min -> 02:00  0.10
+ask +15min -> 02:00  0.10   <-- WRONG (wanted 02:15)
+ask +45min -> 02:00  0.10   <-- WRONG
+ask +60min -> 02:15  0.11   <-- WRONG (wanted 03:00)
+ask +75min -> 02:30  0.12   <-- WRONG (wanted 03:15)
+```
+
+Inside the first hour the `:00` point wins because its hour has not run out.
+**From the second hour on the answer is not even the top of the hour** - the
+first point still inside its own hour wins - so the error compounds.
+
+**What it cost is not "a slightly wrong price".** `arbitrage._act()` tests
+`here.start == v.cheapest.start` / `== v.dearest.start` to decide whether this
+interval is the buy one or the sell one. That identity almost never held, so
+**the strategy idled through exactly the interval it exists to trade**,
+reporting *"this hour is neither the buy hour nor the sell hour"* - and read
+§8.3's `here.provisional` and §17's `price < 0` off the same wrong point.
+`static_tariff.py` emits hourly points, so **static sites were never affected**;
+this was reachable only down the dynamic path TARIFF-08/09 made work.
+
+**The rule now, in one sentence: a point covers from its own start until the
+next point's start, and never more than one hour.**
+
+| | before | after |
+|---|---|---|
+| 900 s | `at(02:15)` -> the 02:00 point | -> the 02:15 point |
+| 3600 s | `at(02:30)` -> the 02:00 point | **unchanged** |
+| **mixed** `[900, 3600]` | each point one hour wide | **each point takes its own gap** |
+
+The mixed case is not an edge case: FCST-04's carry-forward emits **hourly
+carried points beside quarter-hourly firm ones**, and the soak measured spacing
+`[900, 3600]` in **70 % of samples**. A window derived from one global spacing
+would be wrong in the normal steady state.
+
+**The one-hour cap is load-bearing.** FCST-04 leaves an hour *out* of the
+series when nothing published it and yesterday has no value either, and
+`at()` raising `Absence` for that hour is what sends the caller to the static
+profile (§11.4). Uncapped, "until the next point's start" would stretch the
+point before a three-hour hole across the whole hole and answer every instant
+in it with a stale price - filling holes, introduced by the fix for a different
+defect.
+
+**The last point's window is a decision and it is written down.**
+`DECISIONS/TARIFF-14-the-window-a-point-covers.md` §2 argues it: the last point
+is given **the same span as the point before it** (one hour when it is the only
+point). A flat one-hour tail would answer **00:30 tomorrow with today's 23:45
+price**, which is reaching for a neighbour across a day boundary. The cost of
+the choice - a mixed series ending at the firm/carried seam loses its last 45
+minutes to `Absence` - is stated there rather than buried, and the direction is
+the safe one.
+
+**`at()` now reads a point's neighbours, so it would depend on the series being
+sorted - and it establishes that itself** rather than trusting the three
+producers that happen to guarantee it today. The lookup index is sorted by UTC
+start once, at construction; a series handed its 96 points in reverse order
+answers identically, which is a check. `covers()` shared the defect exactly
+(it has no rule of its own - it asks `at()`) and is fixed by the same change;
+`window()` did not (it grades a point's **start** against a range and asks
+nothing about duration), and its docstring now says so.
+
+**Nothing about §9.3 or a point's `start` changed.** `PricePoint` still has
+three fields; the span is derived from the neighbours, not stored.
+
+Graded by `test_price.py` section 13 - 900 s, 3600 s, **mixed**, holes, the
+tail, caller order, `covers()`/`window()` - and end to end by
+`test_arbitrage.py` section 10, which drives `decide()` over a 96-point
+quarter-hourly day whose cheapest and dearest quarters are deliberately **not**
+on a whole hour. Eight mutations, all red, including a **zero-byte** one on the
+tail rule; the table with byte deltas and the checks that were NOT reached is
+in the decision note §6.

 ### TARIFF-09 - the feed is asked for the range the caller wanted