# Lifecycle evidence and hold-time optimization pattern

Use this reference when a Hyperliquid/CryptoTradingBot paper or shadow strategy looks profitable in aggregate but the user questions unrealistic win rates, or when optimizing entry/exit timing from accumulated journals.

## Trigger

- Aggregate scorecard reports implausibly high win rate or profit factor.
- Journals contain a mix of old synthetic/expected-move exits and newer lifecycle exits.
- User asks whether a coin such as WLD should remain eligible because it may be a real edge if well understood.
- User asks to find patterns, especially around hold duration.

## Core lesson

Do **not** treat all `exit` rows as equal live-readiness evidence. First classify evidence quality:

1. **Synthetic-like / legacy rows**: often have identical PnL, no `entry_price`, no `exit_price`, no `exit_reason`, no lifecycle fields. These can inflate win rate and PnL and must be excluded from live-readiness.
2. **Lifecycle exits**: rows with `exit_reason`, `exit_price`, or `gross_pnl_usd`, plus fees/slippage/MFE/MAE/hold fields. Use these for live-readiness and timing analysis.

If a previous response used aggregate rows and produced unrealistic results, explicitly correct the metric and explain the filter.

## Compact analysis recipe

For a strategy journal such as `runtime/experiments/<strategy_id>/trade_journal.jsonl`:

- Filter lifecycle exits: `event == "exit" and (exit_reason or exit_price or gross_pnl_usd)`.
- Compute total and last-N: PnL, win rate, profit factor, median/average PnL.
- Attribute by coin, especially WLD/problem coins.
- Attribute by `exit_reason`.
- Bucket by `candles_held` / ticks held: `0-1`, `2-4`, `5-8`, `9-16`, `17+`.
- Inspect worst losses for `mfe_pct == 0` or poor immediate adverse excursion: this often means entry timing is bad, not merely stop distance.

## Interpretation pattern

- If winners are mostly `take_profit`/`trailing_stop` inside one tick, but 17+ tick `time_exit` rows dominate losses, the edge is immediate-or-not-present.
- If `time_exit` is the largest drag, add a paper-only dead-fish rule rather than widening stops or increasing risk.
- If stop-loss rows show near-zero MFE, prioritize entry quality / anti-chase / retest-reclaim filters over looser stops.
- If WLD has positive legacy PnL but negative lifecycle PnL, do not permanently ban it; keep it as a constrained paper/shadow research coin until fresh WLD lifecycle stats are positive.

## Paper-only optimization pattern

Make changes only in paper/shadow runtime until fresh lifecycle evidence improves:

- Reduce default max hold for the live-candidate paper strategy.
- Add a dead-fish exit: close when a trade fails to achieve minimum MFE after a small number of ticks.
- Add stricter coin-specific hold policy for problem/high-volatility coins such as WLD:
  - shorter max hold;
  - earlier dead-fish check;
  - higher minimum MFE before continuing.
- Journal a distinct exit reason such as `dead_fish_time_exit` so the next scorecard can isolate the change.
- Persist hold-policy parameters into entry journal `extra` for later attribution.
- Keep `paper_trading=true`, `live_order_allowed=false`, `mainnet_signed_action=false` in all generated rows.

Example policy derived from v76 strict lifecycle review:

- strict v76 max hold: 8 ticks rather than 24;
- strict v76 dead-fish: exit after 4 ticks if MFE < 0.18%;
- WLD max hold: 4 ticks;
- WLD dead-fish: exit after 2 ticks if MFE < 0.25%.

Treat these as starting hypotheses, not universal constants. Require fresh evidence before promotion.

## Promotion gate after timing optimization

Before discussing live again, require fresh lifecycle-only evidence after the change, for example:

- at least 50 fresh lifecycle exits;
- total PnL positive;
- last-30 PnL positive;
- profit factor > 1.25;
- WLD lifecycle PnL positive if WLD remains live-eligible;
- no single coin dominates more than ~50-60% of recent trades;
- no live/signed mainnet action occurred during evidence collection.

## Reporting style

When the user asks for recommendations, answer like a risk manager:

- state live status first (`live blocked` / `paper only`);
- give corrected lifecycle-only metrics, not inflated aggregate metrics;
- explain whether WLD is a research edge or current drag;
- state the concrete paper-only change and what evidence is needed next;
- avoid long code logs unless asked.