cascade-heat12-var4-svcal-sensor-nudge

Heat12 is Heat9 plus one deliberately small family-weight update. It retains Heat9's validated integrated-SV empirical-Bayes correction and all Heat8 throughput optimizations. It also adds one narrowly scoped calendar submode inside physical_sensors. Curriculum-start weights, unrelated families, requirements, batching, and prefetch behavior are unchanged.

Weight update

Only two final family weights change:

physical_sensors: 0.085 -> 0.090 (+0.5 percentage point)
chaotic: 0.010 -> 0.005 (-0.5 percentage point)

The final distribution still sums to exactly 1.0. Curriculum-start weights remain byte-identical to Heat9: chaotic already starts at zero, so leaving the start schedule untouched avoids taking early mass from useful AR/seasonal families. The nudge is introduced gradually by the existing interpolation and reaches its full size after curriculum fraction 0.65.

Physical-sensor generating-method update

For 20% of physical_sensors rows, Heat12 adds a low-amplitude pair of Fourier components with:

daily period P sampled from {24, 288},
second daily harmonic at period P/2, with ratio [0.15, 0.40],
matching weekly period 7P (168 or 2016),
weekly/daily amplitude ratio sampled from [0.20, 0.50],
weekly modulation depth sampled from [0.10, 0.30],
total component RMS sampled from [0.15, 0.45].

For fundamental daily wave d1_t, second harmonic d2_t, and weekly wave w_t, define

d_t = d1_t + q*d2_t

and the raw component is

c_t = d_t + r*w_t + m*d_t*w_t.

The product term makes daily amplitude vary over the week. By the product-to-sum identity,

d_t*w_t = 0.5*cos((omega_d-omega_w)t + delta_phi) - 0.5*cos((omega_d+omega_w)t + sum_phi),

so this introduces the mathematically expected sidebands around the daily frequency instead of treating daily and weekly cycles as fully independent. This represents weekday/weekend modulation observed in electricity demand. The bounded second harmonic allows smooth non-sinusoidal and double-peak daily profiles. Its isolated share of daily-profile power ranges from approximately q^2/(1+q^2) = 2.2% to 13.8%, before weekly terms and window normalization.

Heat12 centers it over the generated window and applies

c'_t = (c_t - mean(c)) / sqrt(mean((c_t - mean(c))^2)).

It then adds A*c'_t, where A ~ U(0.15, 0.45). Thus A is the realized window RMS regardless of period, phase, cross-term interference, or incomplete weekly-cycle coverage. This avoids coupling seasonal scale to the sampled calendar geometry.

The submode affects 0.20 * 0.09 = 1.8% of all final-distribution rows. It does not replace the existing physical-sensor seasonal, smooth, front, pressure, bounded, or magnitude/gust components.

The pressure branch rebuilds its output from level, walk, fronts, and the original seasonal term, so it overwrites this added calendar component. Consequently, effective surviving exposure is approximately 1.8% * 3/4 = 1.35% of all final rows. This narrower realized scope is intentional for a conservative experiment.

Five-minute electricity data contain 288 samples per day and 2016 per week; daily and weekly Fourier terms are standard for multiple-seasonality load forecasting, and load models commonly include modulation between daily and weekly/longer seasonal harmonics. See:

Evidence and rationale

Across 10 snapshots (2,663 windows), Heat8's clearest relative weaknesses against Heat3 were:

energy score 0.44756 vs 0.38979 (+14.8%, primarily MWSQL),
5-minute score 0.08578 vs 0.07655 (+12.1%),
hourly score 0.41448 vs 0.37151 (+11.6%),
aemo_nem_5min score 0.08657 vs 0.06422 (+34.8%).

physical_sensors is the closest existing family to sensor-grid, weather, pressure, bounded telemetry, smooth seasonality, fronts, and magnitude/gust behavior. The existing generic seasonal basis included period 288 but did not provide the corresponding 2016-step weekly pair. The new submode supplies that specific multiple-seasonality structure while limiting it to 20% of this one family.

The donor is chaotic, an exotic family with only 1% final mass and zero curriculum-start mass. Reducing it to 0.5% preserves chaotic coverage while avoiding changes to AR2, trend/seasonal, integrated, OU-SV, regime, and count families.

This is smaller than Heat10's 1.5-point rebalance. Heat12 deliberately does not reduce AR2 or alter seasonal-count weights, because Heat8 is already optimized and those broader changes have not been isolated in a matched-token Heat9/Heat10 A/B.

Known evidence from the parent

On the 2026-07-25 matched-token evaluation (462 windows, 100 samples, 8,275,099,648 tokens), Heat9 improved over Heat8:

geomean 0.29086 -> 0.26551 (-8.7%),
MASE 0.99707 -> 0.89867 (-9.9%),
MWSQL 0.08485 -> 0.07845 (-7.5%).

Those results validate the Heat9 parent, not the Heat12 weight/method updates. Heat12 requires a paired Heat9/Heat12 matched-token A/B before promotion, with energy, 5-minute, hourly, daily, sales, nature, and overall MWSQL as guardrails.

Validate

From /home/cascade:

cmp generators/07-26/cascade-heat9/requirements.txt \
  generators/07-26/cascade-heat12/requirements.txt
python3 -m py_compile generators/07-26/cascade-heat12/generator.py
.venv/bin/python -m ruff check generators/07-26/cascade-heat12

The generator diff from Heat9 must contain only the physical-sensor calendar submode. The parsed config diff must contain only name, description, family_weights.chaotic, and family_weights.physical_sensors. Both final and curriculum-start distributions must sum to exactly 1.0.

cascade-plan/cascade-heat12

README.md