# Quant Research Pipeline > Deep reference for the end-to-end quantitative trading research pipeline and how it varies across every strategy domain, systematic / statistical arbitrage, market making and HFT, crypto centralized-exchange trading, DeFi / on-chain (MEV, liquidations, LP), prediction markets, and options / volatility. Use this skill whenever the user is designing, critiquing, debugging, or reasoning about a trading strategy, a signal or alpha, a backtest, an execution model, or risk / portfolio construction, including questions about lookahead / survivorship / overfitting bias, evaluation metrics (Sharpe, information coefficient, deflated Sharpe), market microstructure, inventory management, funding and basis, MEV / mempool / bundles, AMMs and impermanent loss, volatility surfaces and greeks, or probability forecasting and calibration. Trigger it even when the user never says "pipeline", any substantive quant-trading research, strategy-design, backtesting, or alpha-evaluation question benefits from consulting it first. - Skill: `divine572/quant-research-pipeline` (Agent Skill, multi-file: 12 files) - Install (CLI): `npx skillmds@latest add divine572/quant-research-pipeline` - Raw SKILL.md: https://api.skillmd.com/api/skills/divine572/quant-research-pipeline/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: Divine572 (https://skillmd.com/u/divine572) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/divine572/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. | Domain | Reference file | Center of gravity (the hard part) | |---|---|---| | Systematic / stat-arb / factor / trend (CTA) | `references/domain-systematic-lf.md` | Alpha research (stages 3-5); capacity & crowding | | Market making / HFT | `references/domain-market-making-hft.md` | Microstructure, inventory, execution, latency (2, 6, 7, 9) | | Crypto, centralized exchange | `references/domain-crypto-cefi.md` | Data plumbing, cross-venue arb, exchange counterparty risk (2, 6, 7) | | DeFi / on-chain (MEV, liquidations, LP) | `references/domain-defi-onchain.md` | Transaction inclusion & ordering; irreversibility (2, 5, 7, 9) | | Prediction markets / event | `references/domain-prediction-markets.md` | Probability estimation & calibration; resolution risk (1, 3, 4, 6) | | Options / volatility / derivatives | `references/domain-options-vol.md` | Surface modeling & continuous hedging; greeks (3, 4, 6) | ## 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.