A notebook answers a question once. A pipeline answers questions repeatably — with the biases handled in one place, the trials counted, and every promising result already wearing the harness it needs for production. This guide assembles the whole system the other guides cover piecewise: seven stages, and for each one, the artifact it must produce and the gate it must pass. It is also the map of where infrastructure spending actually pays — which is why it links outward to the stack, database, and tooling guides.

The seven stages

idea → data → features → backtest → validation → paper trading → production
  │      │        │          │           │             │              │
 log   raw zone  store    result row   verdict     fill stats     operating
                                                                    stack

1. Idea intake — the experiment log

Every idea gets a row before any code: hypothesis, motivation (a paper? a topic hub? an anomaly in live fills?), and its predeclared success criteria. This log is not bureaucracy — it is the trial counter that makes your deflated Sharpe ratio computable and your significance claims honest. Abandoned ideas stay in the log; they count.

Artifact: one row per idea, append-only. Gate: written success criteria before data is touched.

2. Data — one clean layer, biases handled once

The pipeline’s foundation is a data layer where the classic failures are fixed centrally, so no individual study can reintroduce them: survivorship-clean universes reconstructed as-of-date, point-in-time semantics with knowable-timestamps on every field, raw vendor payloads archived append-only, and verified field semantics (cross-checked against finer data). Vendor selection criteria are in the market-data guide; storage architecture — Parquet + DuckDB first, a real database when it hurts — in the stack guide.

Artifact: the raw zone + a documented loader every study must use. Gate: the five-dead-tickers test and a PIT spot-check, rerun whenever a vendor changes.

3. Features — computed once, leak-proof by construction

A shared feature library beats per-notebook feature code for one decisive reason: point-in-time correctness gets engineered once, with expanding-window transforms and announcement-lag handling built in, instead of being re-risked in every study (leak taxonomy §6). Version the definitions; a changed feature invalidates cached results downstream. This library is your actual IP — treat it like the production code it will become.

Artifact: versioned feature definitions + point-in-time feature values. Gate: every feature passes a one-bar-lag sanity check on a known case.

4. Backtest — a harness, not a script

One backtesting harness, shared by every study, embedding the house rules: next-bar execution, asset-class cost priors with the 1×/2×/3× sensitivity curve computed by default, turnover and drawdown always reported, and results written to a results database — not screenshots — keyed to the experiment-log row. The engine choice matters less than the shared-ness (stack guide’s take); what compounds is that every result in your shop is comparable and countable.

Artifact: a result row (metrics, config hash, cost curve) per run. Gate: the harness reproduces a known-answer strategy to machine precision (the strongest validation pattern).

5. Validation — the adversarial stage

Everything before this stage generates candidates; this stage kills them. The full arsenal is already documented: the eight backtest questions, purged walk-forward with an evaluate-once holdout, parameter-plateau checks, and the DSR hurdle using the experiment log’s honest N. For external ideas, this stage is the reproduction checklist. The output is a written verdict against the stage-1 criteria — by someone wearing the adversary hat, even when both hats are yours.

Artifact: a verdict memo. Gate: production checklist Gate 1, boxes actually ticked.

6. Paper trading — the assumptions meet the market

The strategy runs through its real execution path against live markets at zero size, measuring the one thing no backtest can: the fill-quality gap between simulated and actual executions (the ongoing cost measurement). For venues without good historical depth — prediction markets, long-tail crypto — this stage also begins recording the order books your next research cycle will need.

Artifact: fill-gap statistics vs. backtest assumptions. Gate: gap within pre-set tolerance for 2–8 weeks.

7. Production — the operating stack

The survivor gets the minimal operating stack: the same signal code (never a reimplementation), Postgres as source of truth, kill switch, dead-man alerting, daily reconciliation, tested backups. Live divergence stats flow back into the experiment log — closing the loop, because live performance is the only out-of-sample test nobody can fake, and today’s live anomalies are stage-1 rows for next quarter.

Artifact: a deployed, monitored strategy. Gate: Gates 2–6 plus the go-live ramp.

Build order for one person

Don’t build stages 1–7 as a project; grow them in the order that pays: (1) the experiment log — a table, an afternoon, permanent honesty gains; (2) the data layer’s raw zone + loader (stack guide layer 1–2); (3) the shared backtest harness with default cost curves; (4) the validation ritual as a written checklist; (5–7) only when a strategy earns them. Infrastructure bought ahead of a bottleneck is the trap the stack guide warns about; infrastructure that makes trials countable and biases un-reintroducible pays from week one. Budget the compute side with the cost calculator.

The infrastructure map: research stack → · databases → · production stack → · The evaluation arsenal: backtest questions →