fix: bisect a tie window too long for one exact PWL solve (#624)

[johanzander]

Summary

• A merged tie window longer than the exact PWL solver can certify no longer discards the entire schedule — it is bisected and each half solved under the same certification.
• Fixes the reported symptom: the add-on stuck on "initializing" forever, with every hourly optimization failing identically.

Root cause

detect_tie_windows merges adjacent flagged periods with no cap, so the merged length is an unbounded function of the price curve. run_pwl_window_backward_induction seeds every discharge preimage of the next row's breakpoints, so its breakpoint set compounds per backward step and it can certify only ~8 periods before PWL_MAX_PREIMAGE_SEED_POINTS is exhausted. Raising the budget does not help — measure_tie_coverage.py already documented that a longer horizon "is not reachable by raising budgets".

Nothing owned the join between the two. A nine-period window over volatile SE3 prices raised PWLWindowUnderRefinedError out of optimize_battery_schedule, discarding the whole schedule including every period that solved fine; battery_system_manager turned that into return None; and refresh_health_check re-ran the same effectively-unchanged inputs into the same wall 14 times across two restarts.

The reporter's bit-identical point count of 1,064,944 factors as 10,544 breakpoints × 101 discharge levels — and 10,544 is well under PWL_MAX_BREAKPOINTS (30,000), confirming the preimage cross-product rather than row size is what blew.

Fix

Step 2b catches PWLWindowUnderRefinedError — and only it — and bisects the window at its midpoint, re-solving each half.

This is a re-sizing, not a fallback. Every spliced half carries the same certification a whole window would have; nothing uncertified is ever spliced, and catching it to keep the grid DP's result remains forbidden. P6 is untouched.

Termination is by construction rather than an iteration cap: a horizon-1 window seeds from the four-breakpoint pinned terminal row, so its preimage cross product is ~4 × |discharge levels| — three orders of magnitude under budget, and independent of prices, battery size and grid resolution. A horizon-1 window that still cannot certify is re-raised, because that is not a sizing problem.

Windows are also spliced as they resolve rather than all at once at the end, so a bisected window's second half plans from the SOE the first half actually reached rather than the grid DP's nominal value there. Measured contribution on this fixture: 0.000000 SEK — it closes a latent inconsistency, not an observed error. It is a no-op for separately-detected windows, which by construction never touch.

Test plan

• ./scripts/quality-check.sh passes locally (re-run after merging origin/main)
• .venv/bin/pytest -m slow: 553 passed, 8 skipped
• Observed end-to-end against the reporter's own data, container clock pinned to 2026-08-17 11:08:00 (the minute of the first failure) via libfaketime, using a mock-HA scenario and settings built from the bundle:
  • Near-tied DP decisions detected (#450): re-solving 1 window(s) [(32, 41)] — nine periods, same length as the reporter's
  • PWL window (32, 41) exceeds what the exact solver can certify in one solve (#624) -- splitting at 36
  • Direct Results: ... Savings: 68.61 SEK → Schedule applied successfully
  • systemMode: "normal" (was "initializing"), hasCriticalErrors: false, 96-period schedule, zero Optimization failed lines

Evidence the test discriminates

• Reverted: the if window_horizon <= 1: guard to if True:, i.e. pre-fix behaviour where the exception propagates unconditionally.
• Result: 6 tests FAILED — all four in test_pwl_window_bisection.py, plus test_scenarios.py::test_all_scenarios[regression_2026_08_17_624] and test_plan_faithfulness.py::test_realized_matches_planned_across_all_fixtures (56 passed).
• Restored: tree clean, all 6 green.

The discriminator here is raise-vs-schedule, not a cost delta: pre-fix this input produces no schedule at all.

Outcome-level coverage

• expected_results pinned on the new fixture regression_2026_08_17_624 (auto-discovered by test_scenarios.py), plus its action-selector golden and VPP baseline.
• R == P via run_scenario_realized in test_the_bisected_schedule_is_executable_as_planned, at the corpus-wide 0.001 SEK gate. It was written at 0.01 first, which passed while proving nothing — a tolerance ten times the effect it guards cannot distinguish a clean seam from a broken one.
• A premise guard (test_the_reporters_day_still_merges_a_window_no_single_solve_can_certify) fails if tuning ever shortens this window below the ceiling, so the coverage cannot silently evaporate into the ordinary un-bisected path.

Scope assessment

Structural, and the owner is dp_battery_algorithm.py's Step 2b loop rather than tie_detection.py. The detector is a pure function of tie margins and value slopes with no access to battery_settings, capabilities or dt — the things the affordable horizon actually depends on. A length cap there would be a guess coupling detection to solver internals. Step 2b is the only site holding both the window list and the solver.

Workaround check: the diff adds no parameter, flag, default-fallback, second construction site, or extra trigger. It does not route around an ordering, timing or dependency problem — it makes the work submitted to the solver fit what the solver can certify, which is the problem itself.

Not touched: the generic except Exception: return None in battery_system_manager.py. It is pre-existing and correct as a last line of defence; making it degrade to an uncertified schedule would be a real fallback.

Documentation

• docs/agents/optimizer-architecture.md P6 — new paragraph stating that window size is the caller's problem, that bisection does not relax P6 and is not the cost-gate, and that catching this exception to re-size is permitted while catching it to fall back is not.
• core/bess/exceptions.py — the PWLWindowUnderRefinedError docstring said it "fires on none of the fixture suite's scenarios" and named the budgets as the knobs to revisit. Both pointed the wrong way; corrected.
• docs/agents/bess-knowledge.md and docs/SOFTWARE_DESIGN.md: grepped, neither mentions tie windows, the PWL splice, or any budget this change touches. No update needed.

Why this reached production

The fixture corpus was two periods short of catching it. Measured across all 39 pre-existing fixtures, the longest merged tie window any of them produces is 6 periods, against a solver ceiling of ~8 and the reporter's 9. Only 7 of 39 flag a window at all. No amount of running the existing suite could have found this, and nothing reported how close the corpus was to the cliff.

The sharpest detail: synthetic_extreme_volatility flags zero windows. The fixture whose purpose is volatile prices does not exercise the mechanism volatile prices break.

Contributing causes, in order:

1. An unbounded input met a bounded solver and nobody owned the join. Neither module is wrong alone; the mismatch lives at the call site, which had no opinion about size.
2. The limit was known, in the wrong half of the codebase. measure_tie_coverage.py documents the ceiling and has test_segment_reference_refuses_a_segment_longer_than_the_solver_can_certify. The measurement tooling refused to try; the production path knew nothing and tried anyway.
3. "Never fired" was read as "won't fire." The exception docstring's two true statements both pointed the wrong way.
4. Two changes shipped together and neither re-measured the other. Grid DP discretization leaves 0.01-0.36 SEK/day unrealized on 20/22 benchmark fixtures #512's 0.1 kW grid gives a 10 kW battery 101 discharge levels multiplying every backward step, directly lowering the horizon bug: SOE-grid discretization noise can pick sub-optimal charging window on near-tied periods #450 could afford.

The availability consequence was never sized: a per-window accuracy limit was allowed to propagate through a caller with no partial-success path into return None, then into an hourly retry against unchanged inputs — a guaranteed permanent outage, while the health check reported all seven components healthy.

Note for the reviewer: a separate pre-existing defect this fixture exposes

Adding this fixture breached the corpus-wide zero-tolerance R == P gate by +0.0016 SEK, and it is not caused by this change. Measured, not assumed: with detect_tie_windows patched to return no windows — no PWL solve, no splice, no bisection — the gap is bit-identical at +0.001555.

Cause: at period 32 a 0.0034 kWh solar surplus is an order of magnitude below SOE_STEP_KWH (0.025), so the DP's snapped SOE trajectory cannot represent absorbing it and plans it as export. The command it derives (load_first, charge_rate_pct=100) makes the inverter absorb it anyway. The drift is costless until period 64, where the battery reaches max_soe and the extra 0.0033 kWh leaves that much less room for solar, which is exported instead.

Recorded in KNOWN_PLAN_EXECUTION_GAP_SEK with that evidence. Filed as #630, sized there as negligible (~0.003% relative error, order 0.6 SEK/year): it is a canary for the #497 class, not lost savings.

Closes #624

[bess-agent]

@claude-bot review

[bess-agent]

@claude-bot review

[bess-manager-claude-bot]

Summary

Verified by static review (diff, root-cause evidence, exception raise sites in pwl_window_dp.py, Window dataclass, splice_schedule) — no worktree test run performed for this review, so the PR's stated pytest -m slow / quality-check.sh results are trusted rather than independently reproduced.

Root-cause match: Yes. Stage 2's bess-analyst diagnosis pinned the failure to detect_tie_windows's uncapped merge meeting run_pwl_window_backward_induction's compounding preimage cross-product (~8-period ceiling, confirmed by measure_tie_coverage.py), with battery_system_manager's except Exception: return None turning the resulting raise into a permanent "stuck initializing" outage. This PR's fix targets exactly that join. Note the PR diverges from Stage 2's proposed remedy (a length cap in detect_tie_windows, or a degrade-to-grid-DP fallback) in favor of bisect-and-recertify in dp_battery_algorithm.py Step 2b — correctly, since Stage 2's fallback option would have spliced an uncertified table, which P6 forbids. The PR states this scope assessment explicitly (## Scope assessment), as required by rules.md step 9 / claude-bot.md item 5.

Correctness, verified by reading:

• dp_battery_algorithm.py:2193-2338 (approx): the pending worklist correctly preserves ordering under nested bisection (pending.insert(0, second_half); pending.insert(0, first_half)), and the window_horizon <= 1: raise guard makes termination unconditional rather than iteration-capped.
• Incremental per-window splicing is a genuine no-op for separately-detected (non-bisected) windows: splice_schedule only writes spliced_soe[period + 1] for period in range(w.start, w.end), and since non-touching windows satisfy B.start > A.end, an earlier window's splice never touches a later window's start_soe lookup — confirmed this by tracing the index math, not just trusting the comment.
• The re-derivation-skip fix (resolved_periods / iterating resolved_windows instead of windows) correctly excludes a bisection midpoint from the "period AT end" re-derivation, since that period is now owned by the second half's own flow record (P4).
• cost_basis_trajectory is deliberately left stale across a bisection seam — reward-only impact, not physics; reasonable per the stated rationale, doesn't affect R == P.

Rule compliance: no Optional[x], no hasattr/silent fallback, no new class, no exception-message matching, PWLWindowUnderRefinedError reused (not duplicated) per exceptions.py's "add here, nowhere else." The except PWLWindowUnderRefinedError catch is scoped to exactly one exception type with three raise sites in pwl_window_dp.py (preimage budget, breakpoint ceiling, refine-iteration budget) — all three are horizon-compounding, so bisection is a valid resize strategy for all of them, not just the one in the fixture.

Test coverage: test_pwl_window_bisection.py's four tests do catch a regression — the PR's revert-based falsification (guard → if True) reportedly fails exactly these four plus two slow tests, which is the right shape of evidence per rules.md's "must be seen to fail without its fix." One nit, not a blocker:

• core/bess/tests/unit/test_pwl_window_bisection.py:1916-1930 (test_bisection_splits_at_the_midpoint_and_both_halves_certify) asserts f"splitting at {EXPECTED_HALVES[0][1]}" — i.e. hardcodes that bisection lands at the arithmetic midpoint (80). docs/agents/testing.md's "What NOT to Test" explicitly calls out algorithm-specific boundaries (assert slot_start_times == [...]) as bad tests, for the same reason: a future split heuristic (e.g. bisecting at a cheaper-to-recompute point) that still fixes #624 correctly would break this test for no behavioral reason. The companion test test_an_over_long_window_is_bisected_instead_of_killing_the_schedule already covers the actual user-visible behavior (schedule exists, SOE stays physical) without pinning the split point, so this one test could drop the midpoint assertion and just check that exactly one split occurred, without losing real coverage. Not requesting a change — flagging for the author's judgment given it's a narrow regression-fixture test guarding one historical incident, not general algorithm behavior.

Scope: no scope creep. Touches only the Step 2b loop, the one exception's docstring, the P6 doc paragraph, and test/fixture data. The #630 note (pre-existing sub-grid-step passive-solar drift, measured as bit-identical with tie resolution disabled) is correctly called out as filed separately rather than folded into this fix.

No blockers found.