"RL v3 — Hypothesis lock (multi-asset allocation, allocation-against-baseline)"

Pre-registered before any training. Locked by the operator; only stage 7 reads this back to grade the run.

#Scope (one sentence)

Train a PPO agent to allocate between eqmom (equity momentum) + gate60 (ETH/BTC crypto trend) + cash + a SPY benchmark sleeve, with a Sharpe + drawdown + turnover + drift penalty reward, in a walk-forward 6-month-OOS / 4-year-train setup, and emit a single ADOPT/REJECT ledger entry against the pre-registered bar.

#Pre-registered pass bar

ADOPT requires ALL THREE of:

• OOS Sharpe > equal-weight baseline Sharpe + 0.10
• Bootstrap p (agent > baseline) < 0.05
• OOS max drawdown < 0.30

A miss on ANY one → REJECT. The pre-registered bar is the only bar that moves; we do not loosen it after seeing the result. This mirrors the self_learning_bot feasibility protocol (docs/ROADMAP.md:699-718, 1048-1067) and the reports/rl_oos.md precedent.

#Mechanism hypothesis (the one new thing vs prior attempts)

Prior RL arms in this repo (Stage 1 regime switcher + Stage 2 PPO) closed at REJECT (reports/rl_oos.md: bootstrap p=0.714, Sharpe +0.04 vs gate60 0.98). The diagnosed failure modes were:

1. Reward was per-timestep PnL without risk-adjusted scaling — the policy minimised variance, not drawdown.
2. State was price-only (36 features × 20 lookback × 2 symbols + 4-tail = 1444-dim obs).
3. Train window was too short (<2025-01-01) for the policy to see a regime break.
4. No allocation against a benchmark — gate60 baseline was a comparison number, not the agent's task.

This v3 changes exactly one thing vs prior attempts: the agent is tasked with allocation against a validated baseline, with a Sharpe-ratio reward and a multi-year walk-forward training window. The action space is now portfolio weights over a small sleeve set, not directional timing. That is the new mechanism hypothesis the roadmap's protocol requires for resuming a stopped feasibility study.

#Predicted regime where the agent should win

Crash / drawdown regimes on the equity sleeve, where the equal-weight book keeps deploying at 1/N through the leg down. The mechanism prediction is that an allocator with a drawdown penalty and a Sharpe reward will tilt to cash faster than the equal-weight baseline during the worst deciles of SPX returns, and that this dominates any timing-noise cost on the upside.

This prediction is falsifiable: the audit stage (stage 5) checks per-sleeve attribution by regime. If the agent over-weights the equity sleeve in drawdown regimes, the hypothesis is wrong and stage 7 records it.

#Predicted point estimate (calibrated against the prior null)

• Expected OOS Sharpe uplift vs equal-weight baseline: +0.05 to +0.15.
• Expected bootstrap p: 0.10 to 0.30 (most likely null, per the prior p=0.714 reading).
• Expected max drawdown: 0.18 to 0.25 (the equal-weight book ran ~0.18 max DD; the agent should not be far off).

These are best-guesses pre-registered so we can see whether the actual result beats, matches, or under-shoots the prediction. They are not the pass bar.

#Stop conditions (pre-registered, in addition to the bar)

The run also stops early (writes the rejection ledger entry immediately) if any of these are observed, because they indicate the mechanism is not working at all and longer training will not fix it:

• S1. After stage 2 (baseline replay), the equal-weight baseline itself does not clear a Sharpe of 0.3 on the reconstructed walk-forward windows. If the baseline is dead, we have nothing to beat, and the protocol calls for stopping rather than "finding an edge against a dead baseline."
• S2. After stage 4 (multi-seed OOS), the median agent OOS Sharpe is BELOW the baseline Sharpe (negative uplift, even within noise). A negative-median result is not a high-variance pass; it is the prior, and we should not paper over it with one good seed.
• S3. Stage 6 (net-cost backtest) reduces the uplift by more than 50% of the gross uplift, i.e. the agent is a turnover machine. Per validation/edge_hunt8.md discipline: high-Sharpe gross that dies net is a cost mirage, and we stop before stage 7 votes ADOPT.
• S4. The hyperparameter sweep (stage 3) finds NO configuration with training reward > 1.2 × equal-weight reward on the IS validation split. This means the policy is not learning the reward signal at all; more seeds will not help.

#What stage 7 writes (the deliverable)

• ADOPT path: reports/rl_v3_decision.md with the adoptable spec (env hyperparams, weight caps, sleeve list, kill criteria). The agent becomes a candidate for a separate live-paper plan; this stage itself does not register a runner.
• REJECT path: reports/rl_v3_rejection.md matching the reports/rl_oos.md precedent. The rejection entry is the deliverable — it joins the "what does not work" ledger that future agents read.

There is no middle outcome. A failed run is still a useful result; the repo's protocol rewards the honest null.

#Out of scope (deliberately)

• No start_bots.py registration.
• No production/ runner, no live orders.
• No new data dependency (uses existing sleeve logs + historical reconstructions, or pre-existing parquet caches).
• No replacement of the validated equal-weight book_allocator baseline. The baseline stays the production default until a separate plan adds an allocation runner, and only if this stage 7 votes ADOPT.

#Date locked

2026-09-04