Methodology change noticeNotice date 2026-08-21Effective the first daily evaluation after the founder applies the retune (scripts/retune_watch_conditions.py --apply), no earlier than 2026-08-22. Publish-before-effect (decision of record 2026-07-24 §2) is preserved: this notice is dated and published before any evaluation the new thresholds govern. Alerts already recorded stand as sent.

CLASS · methodology change (watch-condition thresholds). Not a correction — no published value is restated, and no alert already sent is withdrawn.

Methodology change notice — watch-condition thresholds recalibrated to observed distributions

Notice date: 2026-08-21 (UTC; all dates in this notice are UTC) Class: methodology change (watch-condition thresholds). Not a correction — no published value is restated, and no alert already sent is withdrawn. Instrument: watch conditions on dram_spot_pct (DDR5 16Gb 30d and 60d windows) and gpu_rental_pct (GAP-H100 matched-pair 7d window) Effective: the first daily evaluation after the founder applies the retune (scripts/retune_watch_conditions.py --apply), no earlier than 2026-08-22. Publish-before-effect (decision of record 2026-07-24 §2) is preserved: this notice is dated and published before any evaluation the new thresholds govern. Alerts already recorded stand as sent. Rule pack: v1.1.0 unchanged; R-CALL-001 queued (data/governance/QUEUE.md) for the next founder-ruled bump.

1. Why — both live DDR5 thresholds are miscalibrated, in opposite directions

The evidence of record (stored series through 2026-08-19/20):

The 30-day ±15% condition never fired in 71 observable windows. The observed maximum absolute 30-day move is +12.16% (2026-06-25/26) — the threshold sits above everything the series has ever done. A tripwire that cannot trip watches nothing.
The 60-day ±15% condition fired 25 recorded times (2026-07-23 → 2026-08-19) and sits below the observed median (18.78%): 39 of 41 observable windows exceed it. A tripwire that is always tripped alerts on nothing.

Both defects have the same cause: the thresholds were set by judgment, not from the observed distribution of the series they watch.

2. The method

Proposed threshold = the nearest-rank 90th percentile of the observed absolute window-move distribution over the full stored history, rounded to the nearest 0.5 point, ties toward the more sensitive (lower) threshold. GAP windows are chain-linked across declared methodology breaks (data/methodology_breaks.json) so panel re-base echoes never enter the distribution. Rationale: a watch condition should fire on roughly the top decile of observed moves — rare enough that an alert carries information, frequent enough that the condition is demonstrably alive.

3. The arithmetic and the new thresholds

Condition	n windows	median	p90	max	old → new	historical fires old → new
DDR5 16Gb 30d	71	8.95%	11.71%	12.16%	±15% → ±11.5%	0 → 10 (one episode, 2026-06-18 → 06-30)
DDR5 16Gb 60d	41	18.78%	21.64%	22.00%	±15% → ±21.5%	39/41 days → 8 (one episode, 2026-07-23 → 07-30)
GAP-H100 7d (matched-pair)	62	0.00%	14.25%	32.69%	±5% → ±14%	11 → 7 (all marketplace swings)

GTS-1Y 7d ($-delta): p90 $0.24 vs threshold $0.25 — the one well-calibrated condition, and moot: the series suspends from 2026-08-22 and the condition was deactivated by founder order 2026-08-16. No change.

GAP caveat, stated plainly: the GAP distribution is bimodal on a thin two-pair panel — most windows are exactly 0.00% (posted prices static) and the tail is violent (a single vast.ai cluster swing moves the pair median double digits). The ±14% threshold is honest to the observed record but should be recalibrated once the 2026-08-28 panel transition (notice 2026-08-20-panel-admission-and-benching) has 30 observed days on the lambda/hyperstack panel — a further dated retune, not a quiet edit.

4. Mechanism

A threshold change is a new condition row; the old row is deactivated with a dated label annotation, so watch_alerts history stays tied to the exact spec that fired each alert. The seed fallback mirror (data/context/watch_conditions_seed.json) is rewritten to the post-retune live rows in the same apply. scripts/retune_watch_conditions.py — dry-run by default; --apply is founder-run.

5. Conditions are encoded at issue (standing rule, R-CALL-001 candidate)

The defect class behind this notice's second finding: the founding call was issued 2026-05-05; its first watch-condition rows were created 2026-06-11 — a 37-day window in which the call had no encoded tripwire at all. From this notice: every active call carries at least one watch-condition row created on or before its issue date. The nightly auditor check call_conditions_encoded enforces this from 2026-08-21 (the founding call's late encoding is the recorded incident, exempted by date, never repeated). R-CALL-001 is queued in data/governance/QUEUE.md for the next rule-pack bump; the durable fix (a call_id linkage column on watch_conditions) is noted there as an additive migration candidate.

6. Record

Evidence: distribution analysis of dram_spot_pricing (DDR5/16Gb, 101 print dates 2026-05-10 → 2026-08-19) and gpu_pricing (H100 SXM benchmark panel, chain-linked matched-pair, 62 windows) — session output docs/session-outputs/2026-08-21-discovery-loops.md.
Apply script: scripts/retune_watch_conditions.py (founder-run --apply).
Auditor: nightly check call_conditions_encoded (from 2026-08-21).
Governance: call-graduation mechanism docs/decisions/2026-08-21-call-graduation-governance.md.

Document of record: docs/methodology-notices/2026-08-21-watch-condition-retune.md · rendered verbatim from a byte-identical mirror (parity-tested) · nothing above is summarised or re-typed.