# DISMISSED — snapshot risk-off flag records intent=False on a corrupt kill-switch state file (fail-open in the vol sample)

status: dismissed · panel run 21 (2026-09-11), adversarial review · change-review catch on PR #151

---

**Killed because:** the reachability analysis bounds the damage to
near-nothing. The defect is real — `src/thales/execution/daily.py:679-683`
catches the corruption `read_kill_switch_state` deliberately raises
(`state.py:305-309`, "refusing to fail open") and records `intent=False`,
so a genuinely-flat kill-switch day under a corrupt state file would enter
the vol sample and deflate realized vol — the failure class KSP-1's
conjunction was built against. But the ordering saves it:
`_record_portfolio_snapshot` runs at `daily.py:1535` and
`_evaluate_kill_switch` calls `read_kill_switch_state()` **unwrapped** at
:1074 via :1552 — so on a corrupt-file day the run raises and reds loudly
seventeen lines after writing the poisoned row. Contamination is limited to
the day(s) of an incident that is already firing the workflow failure
alert: realistically one or two near-zero rows in a 63-day vol window, far
below the ~1.77× systematic mis-stamping KSP-1 modelled. A two-line
hardening (`intent=None` on read failure; consumer excludes unknown), not a
queue row against a 17/12-cap queue.

**Reopens if:** (a) a corrupt kill-switch state file is ever actually
observed in the wild, or (b) the run's ordering changes such that a
snapshot can be written on a day the run does NOT subsequently red on the
same corruption — i.e. `daily.py:1074`'s read gets try-wrapped, or the
snapshot write moves after the kill-switch gate. Condition (b) is the one
that would make this real; whoever wraps :1074 must reopen this row in the
same PR.