Quant Research Pipeline

Quant Research Pipeline

The lifecycle every quantitative trading strategy passes through, and how that lifecycle bends for each kind of strategy. Use this skill to reason rigorously about any stage of quant research and to catch the mistakes that make a strategy look profitable on paper and lose money live.

Core mental model: it is a loop, not a line

A strategy moves through ten stages, but the apparatus is circular: live monitoring feeds decay signals back into new hypotheses, and the pipeline is really a funnel in which 95%+ of ideas die before deployment. Most of a researcher's time is spent killing strategies at stages 3-5, not shipping them. Internalize that survivorship works against you here too: the strategies that reach production are the rare few that survived honest scrutiny, so honest scrutiny is the whole job.

The invariant spine (ten stages)

These stages exist in every domain. What changes between domains is where the hard part is, what the words physically mean, and which risk dominates, never the skeleton.

1. Idea & hypothesis: articulate why an edge should exist and why it should persist. Who is on the other side and why do they keep losing?
2. Data: acquire, clean, and align, with strict point-in-time correctness. Most silent failures are born here.
3. Signal / alpha: turn raw data into predictive features; evaluate each in isolation before combining anything.
4. Modeling & strategy: combine signals into a view or rule using time-series-aware validation.
5. Backtesting: simulate historically under realistic frictions; defend against overfitting and multiple testing.
6. Portfolio construction & risk: size positions, model covariance, impose constraints, combine alphas into one book.
7. Execution & TCA: get orders to market cheaply; measure realized vs expected cost.
8. Paper / sim trading (the gate): run production-like with no capital; confirm live matches backtest.
9. Production deployment: productionize code, wire OMS/EMS, pre-trade risk, kill switches; ramp size gradually.
10. Monitor & attribute: live P&L, drift, and attribution; detect decay and decide to retire, re-research, or reallocate → back to stage 1.

The full anatomy of each stage, what happens, why, and the failure modes, is in references/stages.md. Read that file for any stage-level question.

Domain selection map

Identify which domain the user is working in, then read the matching reference file on top of references/stages.md. When a question spans domains (e.g. a crypto options market maker), read multiple.

Cross-cutting references (consult for almost every question)

• references/pitfalls-and-biases.md, the bias suite (lookahead, survivorship, overfitting, multiple testing, selection), purged cross-validation, deflated Sharpe, PBO. Read this for any backtest, validation, or "is this real?" question. This is where most money is lost.
• references/metrics.md, evaluation metrics done correctly: Sharpe/Sortino/Calmar, IC/IR, the fundamental law, turnover, capacity, drawdown, deflated Sharpe. Read this whenever a number is used to judge a strategy.
• references/infrastructure-and-roles.md, the research platform, data storage, the research/production wall, reproducibility, and how the work splits across roles (researcher, quant dev, data engineer, trader, risk).
• references/glossary.md, compact definitions of the jargon used across all files.

Operating principles when helping with quant research

Apply these regardless of domain, they encode what separates disciplined desks from amateurs:

1. Demand the economic rationale first. If the user has a signal but no structural reason it should exist and persist (a behavioral bias, a regulatory constraint, a liquidity-provision premium, an information asymmetry), treat it as a likely artifact and say so. A signal with no "who's on the other side" story usually dies at stage 5.
2. Distrust every backtest by default. Before believing a result, ask: were transaction costs, slippage, market impact, borrow, and financing modeled? Was there true out-of-sample separation? How many variations were tried before this one looked good? Point to pitfalls-and-biases.md.
3. Separate the researcher's suggestion from the user's decision. A good-looking backtest is a hypothesis, not a strategy. Keep in-sample and out-of-sample discipline sacred.
4. Match the risk to the domain. The dominant risk is different in each column (adverse selection for MM, exchange counterparty for crypto CeFi, irreversible contract exploits for DeFi, resolution ambiguity for prediction markets). Name it explicitly.
5. Notice the engineering-vs-research gradient. As strategies move from low-frequency stat-arb → HFT → crypto CeFi → DeFi, the edge migrates from statistical research toward engineering and infrastructure: the alpha gets thinner and more contested, and whoever has the faster, more correct, more reliable systems wins.
6. Teach the reasoning, not just the recipe. Explain why a stage or safeguard exists. Prefer first-principles reconstruction over prescriptive lists.

How to answer a typical request

1. Locate the request on the spine (which stage) and in the map (which domain).
2. Read references/stages.md for the stage, plus the domain file, plus any cross-cutting file the question touches (almost always pitfalls-and-biases.md for anything evaluative).
3. Ground the answer in the economic rationale and the dominant risk for that domain.
4. Surface the specific failure mode the user is most likely walking into.