Status: PROPOSAL — no code touched. Decision gate below must be read and pre-registered before any implementation; single run on the OOS window, no iterative re-fitting.
Context
C59 blend (h5+h21, 59-sym mc8 universe, region-A) is live. Validation chain that got it there: sweep → 40-perm MC (p=0.000) → 10k bootstrap → OOS split (tune 2016-20 / test 2021-26, lock tuning before touching test). The same chain applies to everything below.
Rejected levers (ledger — do NOT re-invent):
- Regime entry-gate (SPY≥SMA200 filter on entries): destroyed returns — top config 2.45% CAGR vs 108.9% total (ML_TUNING_FINDINGS §10/§10b).
- Drawdown gates / 0.35 profit-lock / 0.35 drawdown lock: proved harmful/buggy; 0.50 breaker correct (FLAGSHIP_BREAKDOWN §5, PITCH §5).
- Pooled cross-sectional ranker at 500 names (PANEL M1/V1): pooled t = −4.45 (NEGATIVE), NO GO (docs/PANEL.md progress log 2026-08-13).
- Exit_threshold × trend_loose overlay grid: fully swept on C59; no config beats region-A once h21 joins (flagship_expand_59.md).
- Universe densification stride-6: failed; pooled mega-cap sleeve only.
Remaining budget of untested mechanisms in THIS architecture is small — treat every candidate as precious (Bonferroni budget = 3, α ≈ 0.017 each).
Candidate A — Cross-sectional top-k overlay (position selection)
Hypothesis: the flagship scores each symbol against its OWN history (per-symbol
normalization, FLAGSHIP_BREAKDOWN §2) and enters everything above ent=0.05.
Capital is therefore spread over "all names that look good individually" — no
relative preference. A portfolio-level overlay that, on each bar, ranks the 59
names cross-sectionally by combined and caps concurrent book size (e.g.
hold only top-k by rank while still above ent; k ∈ {4, 6, 8}) concentrates
capital on the strongest names and raises PF.
This is untested in the flagship pipeline. It is NOT the PANEL failure: same 59-name universe, same per-symbol walk-forward models, ranking applied only to the execution layer, h5+h21 blend kept intact.
Variants:
| label | mechanism |
|---|---|
| top4 / top6 / top8 | cap book at k names, ranked by blended combined, entries above ent=0.05 |
| topk_soft | cap via position-size multiplier = (k / n_above_threshold), no hard exclusion |
Candidate B — Regime-conditional blend weight (not an entry gate)
Hypothesis: the h5 leg wins in trending regimes, the h21 leg in choppy ones (A21 h21 carried 2026; h5 carried the long history). Instead of fixed 0.5 weight, tilt the blend weight by SPY≥SMA200 state: w = 0.35 h5 / 0.65 h21 in SPY<200SMA chop, w = 0.65 h5 / 0.35 h21 in SPY≥200SMA trend. Single scalar parameter (tilt δ ∈ {0.15}) — NOT a new entry condition, so it cannot repeat the regime-gate failure mode (which excluded trades entirely). ml_active stays AND-of-both to keep the false-enter suppression.
Candidate C — Blend-weight sweep (cheap calibration)
Blend weight is currently fixed at 0.5 (validated). Sweep w5 ∈ {0.3, 0.4, 0.6, 0.7} on the C59 universe only — 4 configs. This is a calibration question, not a mechanism: acceptable ONLY because the OOS window is long (2016-20 → 21-26) and the span is narrow. It is the control arm against which A and B must beat to justify their complexity.
Pre-registered protocol (bind BEFORE running)
- Universe/config fixed: C59 blend, region-A, single harness
simulate(). - Windows: tune = 2016-01-01..2020-12-31 (selection), test = 2021-01-01..end (uncontaminated). Full-window numbers reported but never used for selection.
- Candidate run order (all on the SAME tune window, results frozen): C (calibration) refits w; A and B each tested at their single pre-registered parameter — no post-hoc parameter hunting after seeing test results.
- Selection rule: adopt only if candidate's test-window CAGR ≥ region-A baseline test CAGR + 1.5pp AND test MaxDD ≤ baseline + 5pp AND PF ≥ baseline. A and B additionally must beat the best C calibration by ≥ 1pp test CAGR to justify mechanism complexity.
- Winner gets 40-perm MC + 10k bootstrap (seed 20260820, P(loss) ≤ 0.01) and the OOS split rerun with the winner's exact config before any deployment discussion.
- One shot. If step 2-5 show no winner: stop, document, keep the ledger — no "maybe a different k / different δ" second pass.
Explicitly forbidden
- Re-running any rejected lever (see ledger).
- Selecting configs on full-window or trailing-1y numbers.
- Expanding candidate parameter grids after inspecting test results.
- Touching live bot code or caches before the full validation chain passes.
Deliverables if green-lit
scripts/flagship_topk.py(A) +scripts/flagship_regime_weight.py(B) — research scripts only, on the sharedsimulate()harness (same pattern asscripts/flagship_expand.py).- Frozen
reports/research_candidates_{A,B,C}.mdper candidate with the four-window table + MC table (reproducible). - Decision memo: adopted candidate (with OOS+MC evidence) or ledger entry.
Success criteria (what "better" means)
Beat live baseline (C59, region-A) on the 2021-26 test window — the window the blend already fixes — while holding MaxDD and PF. Anything that only wins on full-window/trailing numbers is a rounding error, not an upgrade.