# QUEUE-10 — HMM regime overlay on the exp-26 book (overlay, not feature)

**Status:** QUEUED · **Priority:** P2 · **Effort:** custom strategy + feature compute + run

## Hypothesis (prove)
Regime flags failed as model **features** (exp 9 idea, exp 25 clean-lake
confirmation that model-specific families regress), but the surviving use is as
an **overlay**: a long-only/regime-gate that holds names only in the favourable
HMM state should cut drawdown / improve net IR on the same signal. Source:
`book/chapters/01` regime section + `chat-ideas.md`
(`TODO(evidence-needed: HMM regime gate as overlay on exp-26 book)`).

## Change vs exp-26 reference (ONE variable)
- **Strategy**: plain TopkDropout (topk 10, n_drop 1) → custom
  `RegimeGateDropoutStrategy`: identical selection, but when the per-symbol
  HMM posterior (`sp_hmm_p_regime1`) is below a calibrated threshold the name
  is held in cash instead of bought (entry gate); no new features enter the
  model — `sp_hmm_p_regime1` is computed for gating only, fit on the train
  window (no lookahead), via `get_lake_sp` with `fit_end=<train end>`.
- All signal/config unchanged.

## Acceptance
- `net_max_drawdown < 7.69%` (reference) AND `net_IR >= 0.21`. If the gate
  never binds at a sensible threshold → the gate is a no-op on this signal
  (exp 20 pattern) → recorded REFUTED/neutral, not a failure.
- Calibrate the threshold on the valid window only (avoid the exp 13/14
  threshold-overfit trap).

## Execution prerequisites
1. Persist `sp_hmm_p_regime1` for the universe (get_lake_sp, fit_end =
   2025-09-01) WITHOUT adding it to `feature_fields` of the model.
2. New contrib module `tac_qlib/contrib/strategy/regime_gate.py`, copy to the
   venv site-packages copy.
3. Workflow YAML wiring the strategy.
4. Trace + run + snapshot.