cascade-heat5-stationary-ar-jump-variance

Heat5 preserves Heat4's AR(1)/AR(2) stationary-scale calibration and adds one new correction to the sparse-jump log-volatility process in regime_shift. The Heat3 curriculum, family weights, all unrelated process parameters, batching behavior, and requirements are unchanged.

AR(2) stationary-scale correction

For

x_t = a1*x_{t-1} + a2*x_{t-2} + eps_t,

with PACF/reflection coefficients a2 = p2 and a1 = p1*(1 - p2), the Yule-Walker equations give

Var(x) = sigma_eps^2 / ((1 - p1^2)*(1 - p2^2)).

Therefore, to make configured sigma the target stationary process standard deviation, Heat5 sets

sigma_eps = sigma_target*sqrt((1 - p1^2)*(1 - p2^2)).

The correction changes only innovation scale. It does not change a1, a2, or the normalized AR(2) autocorrelation function (ACF), which is determined by those coefficients.

The generator currently samples p1 uniformly from [0.3, 0.98] and p2 uniformly from [-0.6, 0.6]. Before calibration, the stationary-SD inflation has mean approximately 1.68, median 1.41, p90 2.61, and theoretical maximum 6.281; approximately 20.2% of rows exceed 2x inflation. The finite burn of 512 can still leave approximately 4% standard-deviation undershoot at p1 = .98 after calibration.

The AR(2) variance identity is derived in this community derivation/reference. The innovation-variance relationship is also supported academically by the Purdue Durbin-Levinson innovation variance recursion notes.

Evaluation rationale and isolation

Heat3's main deficit was MASE 1.6605 versus 1.4093, with daily, sales, nature, and economics slices weak. MWSQL and energy, transport, 5-minute, and hourly (H) slices were strengths. AR(2) receives 20% weight at curriculum start and 10.5% at final weights, so correcting its scale targets early overdispersion while leaving those other strength families and all configuration untouched.

This inherited correction is distinct from the keyupdate.md integrated-SV empirical-Bayes correction. Heat4 now contains both stationary AR corrections; the regime-jump compensation below is Heat5's only additional generator change.

Regime-jump variance compensation

The regime family previously used

log_vol_t = sum(J_i) and vol_t = exp(log_vol_t),

where an active jump has J_i ~ N(0, s^2) with s = 0.5. Although each log-jump is centered, exponentiation makes the noise variance grow with the number of elapsed jumps. For one event,

E[exp(2*J_i)] = exp(2*s^2).

Because vol_t^2 controls the conditional innovation variance, Heat5 applies the exact event compensator

J_i' = J_i - s^2.

The Gaussian moment-generating function then gives

E[exp(2*(J_i - s^2))] = 1.

This keeps the unclipped expected innovation second moment stable over time while retaining the same event times and sampled Gaussian jump magnitudes. Rows with no volatility event remain unchanged. This is the compound-jump cumulant principle described by Kallsen and Shiryaev's exponential-compensator treatment and follows directly from the compound-Poisson moment-generating function.

In a fixed-seed simulation at length 4096, the old clipped multiplier's end/start second-moment ratio was about 5.27; compensation reduced it to about 0.98. The correction necessarily lowers median log-volatility after events (~ -0.63 at the end in that simulation): constant expected variance for a right-skewed multiplier cannot also preserve its median. Clipping to [-3, 3] leaves about 1.7% end variance deflation, so this remains an empirical candidate rather than a guaranteed improvement.

This mechanism is not present elsewhere in the local generators. It is different from the integrated-SV empirical-Bayes normalization in keyupdate.md: that process is stationary and uses a row-level prefix normalizer, whereas this correction removes time-position drift in a sparse compound-jump process.

There is no performance guarantee. A paired Heat4/Heat5 heat A/B is required, with guardrails for MWSQL, energy, transport, 5-minute, and hourly (H) performance. The regime family is 10% at curriculum start and 10.5% at final, so energy and high-frequency slices require particular scrutiny. Ideally Heat4 should first be A/B tested, but Heat5 remains an isolated candidate.

Validate

From /home/cascade, without starting training:

python3 - <<'PY'
import json
from pathlib import Path

root = Path("generators/07-26")
a = json.loads((root / "cascade-heat4/config.json").read_text())
b = json.loads((root / "cascade-heat5/config.json").read_text())
for key in ("name", "description"):
    a.pop(key)
    b.pop(key)
assert a == b
print("config metadata-only diff: OK")
PY

diff -u generators/07-26/cascade-heat4/generator.py \
  generators/07-26/cascade-heat5/generator.py
cmp generators/07-26/cascade-heat4/requirements.txt \
  generators/07-26/cascade-heat5/requirements.txt
python3 -m py_compile generators/07-26/cascade-heat5/generator.py
.venv/bin/python -m ruff check generators/07-26/cascade-heat5
docker run --rm \
  --entrypoint /root/cascade/.venv/bin/cascade \
  -v "$PWD/chain.toml:/workspace/chain.toml:ro" \
  -v "$PWD/generators/07-26/cascade-heat5:/workspace/candidate:ro" \
  ghcr.io/tensorlink-ai/cascade-worker@sha256:f73c77276b80942c61e7c5570bbbafbd69c8fd15e79cffbbcf75c8855715c9a0 \
  verify /workspace/candidate --chain-toml /workspace/chain.toml

Relative to Heat4, the generator diff must contain only the regime-jump compensation block and its comment. Requirements must remain byte-identical. Validation must not start training.

cascade-plan/cascade-heat5

README.md