Phase 6 — Search-space expansion design (automated strategy search harness)

Phase 6 — Search-space expansion design (automated strategy search harness)

Status: design draft (not started). The start condition, "validate the whole pipeline", has been met. Principle: the harness is not a strategy factory but a hypothesis filter. Whatever passes still goes through the same D-010 gate.

1. Why a harness (the problem with repeated manual variants)

• Manual variants like "let's also try a Bollinger touch version" are uncounted multiple testing — the probability that the 10th variant passes by chance accumulates, and without records it cannot be corrected.
• The harness does the same search but (a) the machine forces a record of the number of attempts, (b) corrects with the Deflated Sharpe and (c) applies the same protocol to every candidate. Freedom of search + statistical honesty at the same time.

2. Search-space grammar (combination generator)

Strategy = entry block × exit block × filter block × parameters. Blocks reuse the existing indicator layer.

[Entry]  bb_touch / bb_close_below / bb_squeeze_break / rsi_cross(level)
        / donchian_break(n) / ret_zscore(n, k) / vol_spike_revert
[Exit]  rsi_cross_back / bb_mid_touch / time_exit(bars) / atr_stop(mult)
        / donchian_opposite(n) / trailing_atr(mult)
[Filter]  trend_sma(n, above|below) / vol_regime(atr_pctile, lo|hi)
        / funding_sign / none
[Direction]  long / short / both

• v1 size estimate: entry 7 × exit 6 × filter 4 × direction 2 × parameters ~8 variations ≈ thousands of combinations. 1h train 21k bars × 0.3s/run → a few hours locally. Sample combinations if needed.
• Implementation: src/harness/grammar.py (block definitions, combination generation), src/harness/runner.py (execution, recording, checkpointing, resume); results in reports/harness_{run_id}.csv + the cumulative reports/harness_ledger.csv (a single ledger of every historical attempt — the DSR denominator).

3. Statistical discipline (the core of the harness)

1. Mandatory ledger: every run is appended to the ledger (combination definition hash, date, train Sharpe). A culture of not trusting any backtest result without a run_id.
2. Deflated Sharpe Ratio: subtract the expected Sharpe of "the best of N" using total attempts N and Sharpe variance. Train pass line = DSR significance (e.g. p<0.05) — not a simple Sharpe ranking.
3. Funnel: train DSR pass → val comparison (collapse fails) → walk-forward → all automatic up to this point. Only survivors get human review → D-010 gate (3 months of incoming data + paper).
4. Human review items: whether the mechanism can be explained (why it makes money, in one sentence — if not, hold even with good statistics), correlation with the existing record, capacity constraints.
5. Regime-split report: per candidate, a performance breakdown across up/down/sideways periods (reusing the plan 3.3 regime classifier).

4. Implementation order (when started)

1. grammar + runner skeleton, ledger design — 0.5 days
2. DSR implementation + unit tests (check the false-positive rate on synthetic null data — important) — 0.5 days
3. 1st run: 1h BTC train, ~2 thousand combinations, report funnel pass rates — a few hours locally
4. Universe-expansion run (13 symbols): cross-symbol consistency check of surviving candidates — a strong signal of robustness

5. Roadmap after the harness

5a. Pair trading (strategy 4 — can run in parallel with the harness)

• Cointegration tests (Engle-Granger, rolling), spread z-score entry/exit, rolling hedge-ratio updates.
• Data ready (13 symbols, 1h). Needs a separate simulator (two legs — see the funding_arb.py structure).
• Caution: cointegration of coin pairs is unstable compared with stocks [inference] — trade only in periods passing the rolling test.

5b. When a surviving strategy is confirmed — Phase 7 paper trading

• Testnet bot: rehearsal of live code (sharing the signal module with the backtester — plan 8.1 structure)
• Measure: deviation (<20%), measured slippage vs the assumed 0.05%, skip rate, uninterrupted uptime
• Need to resolve the open D-007 item: staged capital × minimum-order conflict → a sizing exception rule for the paper period
• Infrastructure: VPS ($5~10 per month) — the recorder moves there too

5c. Liquidation data strategy (after 3+ months of recording)

• Hypothesis: collecting limit fills during a cascade (the D-013 revisit condition)
• Use recorded data to verify how real liquidations map to 1m candle fingerprints → quantify proxy quality

5d. Long term (after securing capital and a track record)

• Multi-strategy portfolio (plan 5): inclusion requires a correlation coefficient < 0.3 — not reached, since 0 strategies are admitted now
• Revisit when capital increases: universe expansion (mid-cap liquidity), larger K, real-spec sizing

6. What will not be done (explicit)

• OFI/order-book depth: an edge below the cost floor + an HFT competition zone — on hold, confirmed by re-review
• Reviving parameters of dead strategies (D-009/D-013)
• Reusing the test partition (already consumed)
• ML black boxes (unexplainable mechanisms): outside the harness grammar — would damage track-record credibility