The strategy lab

The lab is where you develop a strategy by hand. It is the operator's view onto the pipeline: a place to browse every strategy by stage, run backtests and parameter optimization, submit a strategy to the gauntlet, read the robustness verdict, and — if the evidence holds — promote it to paper (the public site calls a paper-stage strategy a "candidate"). It lives at the /lab route, with a detail page for each strategy at /lab/strategy/[id].

Think of the lab as the manual counterpart to the autonomous research daemon. The daemon runs this same loop continuously, at scale, without you clicking. The lab lets you drive one strategy through the same gates yourself and see exactly why it advances or dies.

Forven is a research tool. Backtest, optimization, and gauntlet results describe past and simulated behavior; they are not predictive, and nothing here is financial advice. Surviving the lab is evidence of discipline, not a promise of profit.

What the lab is for

The lab does four things:

• Browse the pipeline. See every strategy grouped by lifecycle stage and status, sorted and filtered however you need.
• Test and optimize. Run a fresh backtest, sweep parameters with grid search, and validate the winner with walk-forward.
• Run the gauntlet. Submit a strategy to the robustness battery and watch each step pass or block.
• Promote. When the readiness checklist is satisfied, promote a strategy to paper — directly, or with an operator override and a logged reason.

The lab does not move real capital. Promotion ends at paper; the path to live routing on HyperLiquid runs through a separate, much stricter gate, and beta builds hard-lock to paper regardless.

The pipeline view (/lab)

The main lab page is a searchable strategy list. Strategies are grouped into three buckets:

• active — strategies still moving through the pipeline (quick_screen, gauntlet, paper, live_graduated).
• parked — strategies set aside but not discarded.
• trash — archived or rejected strategies, kept for audit.

Each row shows the strategy's symbol, stage, status, and headline metrics. You can sort and filter by symbol, stage, and status to find what you need. The list refreshes in real time on lifecycle events such as strategy_promoted and kill_switch, so the board stays current without a manual reload.

A note on stage names. The real pipeline stages are quick_screen → gauntlet → paper → live_graduated, with terminal stages archived, rejected, and research_only. Stages are immutable once assigned — only a promotion or demotion transition changes them. The public site simplifies these to screen / gauntlet / candidate / live; the lab shows the real names.

The strategy detail page (/lab/strategy/[id])

Clicking a strategy opens its detail page — a multi-tab workspace that is the heart of manual development.

Configuration

The configuration tab holds the strategy's identity: type, symbol, timeframe, trade mode (long_only, short_only, or both), and its current parameters. This is where you edit params before a rerun. Note that execution-level risk knobs (stop-loss, take-profit, sizing) are execution controls, passed separately from strategy params by design — see Backtesting a strategy for why that separation exists.

Backtests

Every backtest the strategy has run, with its equity chart, trade-history overlay, and metrics. The engine always splits data 70/30 into in-sample (IS) and out-of-sample (OOS). Read the OOS numbers — IS is optimistic by construction. Metrics carry reliability flags (Sharpe is unreliable below 20 trades; annualized return below a 3-month window), and the lab suppresses the unreliable ones so a glittering figure on a short run does not mislead you. The full metric catalog lives in Metrics.

Optimizations

Grid-search and walk-forward results. Optimization sweeps the strategy's parameter space and ranks candidates by fitness; walk-forward then validates the winner across folds. This tab is where the robustness verdict and the per-test gauntlet results appear.

Execution

The strategy's lifecycle timeline — stage transitions, promotions, demotions, and the audit trail behind each. When a strategy is parked at a gate, this is where the gate-rejection reason shows up.

Optimizing a strategy

A single backtest is one data point. Before the gauntlet, you usually optimize the strategy's parameters so the gauntlet validates a tuned configuration rather than an arbitrary one.

Grid search explores the parameter space via Latin Hypercube Sampling. It samples up to 200 combinations (a deterministic seed keeps runs reproducible), backtests each, and returns the top 5 ranked by fitness. Fitness is a 0–100 composite weighting Sharpe (30%), win rate (20%), profit factor (20%), max drawdown (15%), and trade count (15%).

# Grid search + walk-forward in one call (the lab uses this under the hood)
$body = '{"strategy_id":"<id>","symbol":"BTC/USDT","timeframe":"1h"}'
curl.exe -X POST http://127.0.0.1:8003/api/strategies/optimize `
  -H "Content-Type: application/json" -d $body

The best parameters are applied to the strategy automatically, and you can then run walk-forward to confirm they describe a real basin of edge rather than a single lucky coordinate. The optimizer drops inert risk fields from its mechanical search space, so a stop-loss buried in params cannot silently change a backtest.

A useful guardrail: after optimization, the engine keeps the existing metrics if a rerun produces a lower Sharpe (the "best-of" rule). A short rerun cannot downgrade a strong baseline.

Running the gauntlet from the lab

The lab is where you submit a strategy to the gauntlet — the robustness battery of walk-forward analysis, Monte-Carlo bootstrap, parameter jitter, cost-stress, and regime-split. A strategy must already have cleared quick_screen (with distinct out-of-sample evidence) to be admitted.

Steps

1. Open the lab at /lab and find a strategy sitting at the quick_screen stage.
2. Open its detail page at /lab/strategy/[id].
3. (Optional but recommended) optimize parameters in the Optimizations tab first.
4. Submit the strategy to the Gauntlet.
5. Watch the step progress tracker in the Backtests / gauntlet panel as each step claims, runs, and either completes or blocks.
6. Read the robustness verdict and the PromotionReadiness checklist.
7. If the readiness checks pass, click Promote (provide a reason for a manual override).

What you'll see: the gauntlet renders each test's status (pending, running, passed, blocked_*, failed_gate) alongside the artifacts it produced — walk-forward degradation, Monte-Carlo drawdown, jitter pass rate, regime coverage — plus a composite robustness score on a 0–100 scale. Walk-forward returns a clear PASS or FAIL. A FAIL is the system working: most strategies do not survive, and that filter is the point. The deep mechanics of each test live in The gauntlet.

If a strategy fails a gauntlet test, it is demoted back to quick_screen. After three demotions it is redirected to research_only and removed from the tradable pipeline, so repeat failures stop burning compute.

The promotion-readiness checklist

Before you can promote a strategy to paper, the lab runs a readiness checklist. It verifies that the evidence actually exists:

• a multi-timeframe backtest sweep (3+ timeframes), and
• the gauntlet validation artifacts — walk_forward, monte_carlo, param_jitter, cost_stress — all persisted and passing.

Each check returns pass, fail, or skip. You can query it directly:

# Promotion readiness (the lab calls this before showing the Promote button)
curl.exe http://127.0.0.1:8003/api/strategies/<id>/readiness

Passing the lean gauntlet→paper gate is deliberately achievable — robustness >= 50/100, return >= 0%, drawdown <= 30%, OOS profit factor >= 1.05 — so the funnel keeps moving even in adverse regimes. The gate that risks real capital, paper→live, is far stricter and is documented under promotion gates. Capital gates cannot be force-bypassed by automated actors; only an operator (or the decay kill-switch) can override them.

Promoting to paper

When readiness is satisfied, promote:

1. On the strategy detail page, click Promote.
2. If you are overriding a near-miss gate, check the override box and enter a reason — overrides require explicit consent and are logged for audit.
3. The promotion queues as an approval in the approvals panel (unless auto-approval is enabled).
4. An operator approves it; the strategy transitions to the paper stage.

Once promoted, the strategy trades against the live price feed with no real orders sent. Watch it in paper trading. Paper PnL will not reconcile with any exchange, because nothing was routed there — that is expected, not a bug.

The Lab Orchestrator (continuous discovery)

Beyond manual development, the lab has an autonomous side: the Lab Orchestrator, a continuous regime-discovery loop. On a configurable cadence (default 12 hours) it plans a candidate batch, builds or reuses a regime classifier, tests the pool against market-regime segments, ranks by fitness, and promotes champions to paper.

You configure and monitor it via the lab config endpoints:

# Inspect the orchestrator's current config and status
curl.exe http://127.0.0.1:8003/api/lab/config
curl.exe http://127.0.0.1:8003/api/lab/status

# Manually enqueue one discovery cycle
curl.exe -X POST http://127.0.0.1:8003/api/lab/cycle

The orchestrator's status moves through idle → queued_model → queued_segments → queued_matrix → idle. Cadence, strategy sources (active / registry / graveyard), champion dwell time, and score-delta thresholds are all configurable. This is the same loop the research daemon drives at scale.

Caveats

The lab is beta software. A few honest edges:

• OOS is the truth. Treat in-sample metrics as a sanity check, never a forecast. The lab suppresses unreliable metrics for a reason.
• Implausible metrics are rejected, not celebrated. A Sharpe >= 5 or profit factor >= 8 on honest crypto data is treated as a look-ahead leak and blocked at the gates. If a strategy looks too good, the lab assumes it cheated.
• Promotion ends at paper. Surviving the lab earns simulation, not capital. The strict paper→live gate is separate, and beta builds hard-lock to paper.
• Backtests are process-isolated. Long or large runs may time out (base 60s plus 8s per 1k bars, capped at 300s for backtests; longer for walk-forward). A timeout is a compute limit, not a strategy verdict.

Related

• The gauntlet — the robustness battery you run from the lab
• Backtesting a strategy — the backtest studio and the 70/30 IS/OOS split
• Promotion gates — the achievable-paper and strict paper→live gates
• Paper trading — where a promoted strategy runs next