Two defects surfaced by the 2026-08-01 production run.
The generated report's "Applying these weights" section claimed the
JSON was inert until someone wired it into BandConfig. That stopped
being true when BandWeights landed: BandConfig.weights/1 consults
BandWeights.lookup/1 ahead of the in-source :weights override and the
global @weights default, so band_weights.json is a live scoring input.
Anyone reading the report would have concluded a recalibration run was
a no-op. Replace the paragraph and document the operational half that
was missing entirely -- BandWeights caches into :persistent_term on
first read, so a running node serves the previous weights until it is
redeployed or BandWeights.reset/0 is called.
PSKR_BAND_TO_MHZ was missing 9cm, so every run logged "skipping unknown
PSKR band" and dropped those rows from the corpus accounting. Weight
derivation is unaffected -- 3400 MHz is not in PSKR_BANDS, so it still
routes to the contacts fit (source=contacts, n=334, unchanged). The
dict already carries other non-routed bands (23cm, 13cm, 3cm); 9cm was
simply absent.
Replace the two-script Python pipeline (analysis report + Elixir-source
emitter) with a single `scripts/recalibrate.py` that fits per-band
weights from PSKR spot density (VHF/UHF) and contacts↔HRRR correlations
(microwave), writing `priv/algo/band_weights.json` as a machine-readable
artifact. A new Elixir BandWeights module loads this JSON once via
`:persistent_term` cache; BandConfig.weights/1 consults it before falling
back to in-source overrides or global defaults. The script never touches
Elixir source — recalibration is now `python3 scripts/recalibrate.py`
followed by an app restart.
