Skip to content

Research to Production Workflow

A strategy passes six gates on its way from idea to live capital, and each gate corresponds to a way strategies die. Here's what each one catches, and which gates Arithmion welds shut in code.

6 of 8 ~12 min

A quant strategy is a hypothesis about how markets work. The interesting thing is that when strategies die, the hypothesis is rarely the problem — the problem is testing it at the wrong scale, at the wrong speed, with the wrong metrics. The classic failure script: a researcher finds a factor with IC = 0.04 in-sample; a backtest shows Sharpe = 1.8; 30% of capital goes live and the Sharpe comes back 0.4; only then does anyone discover the in-sample fit was overfit, the backtest was contaminated, and 30% was recklessly large; the strategy is killed. A team can burn 6-12 months on this cycle, along with real money and their credibility with investors.

Every step of that script could have been intercepted earlier and more cheaply. That is the entire rationale for staging: gates are cheap, mistakes are expensive. A strategy that dies in research costs a few weeks of compute; one that dies in deployment costs money and reputation. The workflow has exactly one design goal — expose each failure mode at the cheapest possible point. This article walks the six stages along that line, then looks at which of the gates Arithmion welds shut in code.

Stage 1: Research — Open-Ended, but the Exit Narrows

Research is factor discovery, model training, and initial backtesting. It’s the only stage with no upper bound on duration: weeks to months is normal, and it’s done when you find something promising. The output is a candidate strategy — a factor, a model, a target horizon, an initial backtest. A respectable candidate looks something like: cross-sectional IC > 0.03 sustained over 60+ months, IC IR (mean IC over its standard deviation) > 0.3, in-sample Sharpe > 1.0.

But the exit from research is not judged on in-sample numbers. To advance, the candidate faces the anti-self-deception battery: DSR (deflated Sharpe ratio) > 0.95, PBO (probability of backtest overfitting) < 0.25, walk-forward Sharpe > 1.0. Fail any of them and it’s back to the bench — refine the factor, change the model, or find a different idea. Don’t argue with the gates: if the strategy can’t pass them, it most likely has no edge.

One honesty detail here. DSR’s meaning depends on the trial count: try 100 variants, report only the best, and your DSR is artificially inflated. Tooling can track the trials it sees, but you can always fool yourself by not reporting the full search. “DSR is 0.96, we’re good” is only a meaningful sentence when the trial count is honest — this is one of the few gates in the workflow that only you can hold.

Stage 2: Validation — Filtering Out the Regime Bets

Research handed you a candidate; validation changes the question. It no longer asks “is there a signal” but “does the signal survive in worlds you haven’t seen.” Out-of-sample testing, stress tests across regimes (windows like 2008, 2020, 2022), capacity modeling, and correlation analysis against your existing strategies all live here. Expect 1-3 months, mostly compute — hundreds of configurations, each run taking minutes to hours.

A respectable validation battery runs somewhere between a dozen and twenty distinct tests, and its output shouldn’t be a single pass/fail boolean but a structured report: the Sharpe in each regime window, the shape of the drawdowns, where the capacity estimate lands. That report is an asset in its own right — every later stage’s expectations come from it.

The exit criteria change register too: purged walk-forward Sharpe > 0.5 after realistic costs, no regime window with Sharpe below -1.0, a capacity model showing edge at the intended scale, and DSR still holding 0.95 across cross-validated variants.

The “no regime Sharpe < -1.0” condition deserves its own paragraph. Something that’s great in 2010-2019 and terrible in 2022 isn’t a strategy — it’s a regime bet. What it earned wasn’t alpha; it was the luck of a decade that happened to suit it. Catching these impostors is the number-one reason the validation stage exists. The 2022 rate-hike cycle crushed a generation of momentum strategies that looked beautiful over 2010-2021; the survivors were the ones that had been baked against 2008-2009 data.

Stage 3: Paper Trading — Testing Operations, Not Alpha

By this point the strategy’s statistical properties have been audited; paper trading audits something else: the infrastructure. Live data, simulated fills, no real money. Confirm the pipeline runs on live data without errors, the signal fires on schedule (no missed trades, no duplicates), the risk and sizing logic actually engages — and measure the one number that matters most: where paper Sharpe lands relative to backtest Sharpe.

The realistic expectation is 50-70%. Note which direction this threshold cuts: if paper Sharpe matches the backtest exactly, be suspicious — backtests are always optimistic, and zero decay means something is lying to you. 70% is excellent. 30% means an execution or capacity problem: diagnose before advancing.

Duration should be 3-6 months, and that number isn’t arbitrary: it needs to be long enough to span at least one volatile stretch. A strategy that paper-trades through six calm months hasn’t been tested at all — you need to watch it react to a volatility spike, even a small one. This requirement gets missed constantly, because “nothing happened” looks like “it passed.”

Stage 4: Pilot — First Contact with Real-World Friction

The pilot uses real money, but only 10% of intended capital, for 3-6 months. That 10% is a calculated number: small enough that the strategy can’t move the market, so what you’re testing is execution, not capacity. Fills are real, slippage is real, and every rough edge of the broker integration surfaces at once.

The exit checks three things: pilot Sharpe reaching 60% of paper Sharpe over 3+ months; no operational failures (missed orders, bad fills, data outages); slippage and impact within 20% of paper estimates. Pilot Sharpe far below paper means a real-world execution problem — broker integration, latency, fill-model mismatch. Diagnose before scaling.

One common surprise is worth flagging in advance: pilot Sharpe often comes in higher than paper. Usually this is because the simulator modeled liquidity conservatively — real markets are slightly more liquid than it predicted. Don’t get excited; the difference is usually within noise.

Stage 5: Deployment — A Ramp, Not a Cliff

From 10% to 100% is not one step but three: 25%, 50%, 100%, roughly four months each, about 12 months total. Every step answers the same question: has Sharpe degraded with scale? A sound standard: each step’s Sharpe stays within 70% of the previous step’s. If any step drops more than 30%, stop the ramp and diagnose.

Capacity degradation is the most common way strategies die at scale. What works at $1M may not work at $100M — at $100M, you *are* the market impact. Almgren-Chriss-style impact models predict impact scaling as $\sqrt{Q/V}$, but reality is messier: bid-ask bounce, queue position, and information leakage all make real impact larger than modeled. The capacity model made its prediction back in validation, but the true test is the ramp itself — which is exactly why the ramp is slow. The cheapest way to discover a capacity wall is to hit it with 25% of your capital, not 100%.

Stage 6: Monitoring — The Rest of the Strategy’s Life

Going live isn’t the finish line; it’s a change of habitat. Monitoring is indefinite: live metrics against expectations, alerts, periodic re-validation, retraining as needed. Re-validation triggers include: live Sharpe more than 30% below expectations, drawdown beyond threshold, detected IC decay, capacity utilization above 80% (you’ve started moving prices). When triggered, the strategy re-runs stages 2-5. Pass, and it keeps running; fail, and it retires. Re-validation isn’t punishment — it’s this workflow’s standing loop for the rest of the strategy’s life. The gates don’t disappear after launch; they just start knocking on a schedule.

Alerts are signals, not noise. “Live is 0.9, backtest was 1.2, that’s just noise” — maybe. But a 30% Sharpe drop is a meaningful event, and a 50% drop is a strategy that needs re-validation or retirement. The typical cost of ignoring alerts is 6-12 months of declining returns followed by forced retirement — by which point the strategy has often decayed past what a re-fit could save. This topic is big enough that the next article, on model monitoring and retraining, is entirely about it.

The Gate Matrix: Homework You Can Copy

Here are the six exit criteria in one table. To be clear about its status: this is a defensible threshold configuration from industry practice. The specific numbers (0.95, 0.25, 50-70%, and so on) are experience-based values you can tune to your strategy type — they are not physical constants. But the failure mode each row intercepts is real, and deleting a row means giving up protection against that particular way of dying.

TransitionCriteriaFailure mode intercepted
Research → ValidationDSR > 0.95 AND PBO < 0.25 AND walk-forward Sharpe > 1.0Multiple testing bias, configuration overfitting
Validation → PaperPurged CV Sharpe > 0.5 AND no regime Sharpe < -1.0Regime bets
Paper → PilotPaper Sharpe within 50-70% of backtestInaccurate execution model
Pilot → DeployPilot Sharpe at 60% of paper for 3+ monthsOperational issues
Deploy → MonitorSharpe stable through the 25% → 50% → 100% rampCapacity constraints
Monitor → Re-validateLive Sharpe drops > 30% OR drawdown > 10%Decay and regime change

The gates are unforgiving for a reason: each one stands on a pile of strategies that died the same way somewhere else. If you catch yourself arguing with the gates or hunting for ways around them, you’re arguing with the accumulated experience of everyone who lost money by skipping a step.

Which Gates Arithmion Welds Shut in Code

Everything above is methodology. On the Arithmion platform, the critical spans of this lifecycle are not “recommendations” — they’re enforced in code. The real gate chain looks like this:

run_backtest(..., walk_forward=...)   # produces a run with an out-of-sample block
        ↓
validate_run(run_id)                  # statistical validation: DSR, OOS, sample size
        ↓
promotion_check(run_id)               # no passing verdict = no promotion eligibility
        ↓
create_paper_deployment / start_...   # the farthest an agent can go: paper trading
        ↓
(live promotion)                      # no such tool exists on the platform — humans only

Several rules are hard. Run a backtest without a walk-forward configuration and the run has no out-of-sample block at all; validate_run will report “No out-of-sample result present (required)” every single time — and note the semantics: that verdict is about missing evidence, not a bad strategy, and the remedy is to re-run with walk-forward. The built-in statistical validator’s defaults (DSR floor of 0.95, out-of-sample required) act as a floor: any configuration you pass in is clamped item by item against the defaults, and can only be stricter, never looser — the “edit the config to dig under the gate” path does not exist at the code level. promotion_check accepts only a passing validation verdict; backtest results brought in through import_run are marked origin=external and carry no promotion eligibility by default — numbers the platform didn’t watch being produced are not grounds for deploying capital. On the deployment side, when an agent creates a deployment, mode is not a parameter — the code hardcodes paper. And “promote to live” has no tool on the platform at all; that step is always a human decision.

What all this enforcement buys is auditability. When a strategy loses money, the first question is always “did it pass all the gates?” If yes, the loss came from the market; if no, it came from skipping gates. With every run carrying its metrics and verdict, and every deployment its mode and state, that question is answerable at any moment.

How Strategies Die: Four Real Scripts

Skipping paper trading. “The backtest looks great, let’s just go live with 5%.” What gets skipped is operational validation: real fills differ from simulated ones, broker APIs behave differently from research code, data refreshes on different schedules. The cost is typically 1-3 months of debugging in production, sometimes a compliance problem (trading live without proper testing documentation), and always a credibility hit with the team.

Scaling too fast. “The backtest Sharpe is great, deploy at 50%.” Capacity is real, and it only reveals itself after you’ve lost money at the larger scale — losses proportional to the size mismatch. The ramp timeline can be compressed; the steps cannot be skipped.

Ignoring regime stress. “Backtest looks good over 2020-2024, ship it.” What about 2008? What about 2022? A strategy that has never been through a regime change is a strategy you don’t understand — and the next crisis will teach you the lesson, tuition payable in capital.

Treating DSR as a checkbox. As above: DSR only means something when the trial count is honest. Report the number of variants you tried, not just the best one.

The Realistic Timeline

The actual rhythm of one strategy from idea to full deployment: research 2-4 months, validation 1-2 months, paper 3-6 months, pilot 3-6 months, ramp 12 months, monitoring indefinite. Total: 21-30 months. That’s not slow — that’s realistic. The comparison group for “slow” is the classic failure script that burns 6-12 months and leaves nothing behind.

Most strategies die in stages 2-4: they fail validation, fail paper trading, or fail the pilot. That is the workflow working, not the workflow failing — its whole purpose is to kill bad strategies cheaply, before real money is at risk. The 5-10% that make it through all six stages are the ones with actual edge: validated, production-tested with small capital, scaled gradually, watched continuously. Their live Sharpe is real.

Retirement Is Part of the Workflow Too

Even strategies that pass all six stages eventually retire, and the causes come in four kinds: decay (the factor’s predictive power fades — IC drifting from 0.05 to 0.01 over a typical 3-5 years), capacity (the strategy’s market shrinks, or its allocation outgrows it), regime change (the factor that worked for 20 years stops), and better alternatives (a new strategy with better risk-adjusted returns).

Retirement should leave a record: when, why, and what the final metrics were. Retired strategies stay in the record for analysis — comparing them against active ones is the cheapest textbook on strategy lifecycles you will ever get.

The six-stage workflow, together with point-in-time data, the backtest engine, and the validation gates, is the system that turns research results into production results; the infrastructure exists to make the workflow enforceable rather than optional. The next section of the learning path covers strategy archetypes — momentum, mean-reversion, factor-based, alternative data — each walked through this same pipeline.

References

  • López de Prado, M. Advances in Financial Machine Learning, §1.3.1.6 (Portfolio Oversight). Wiley, 2018. ISBN: 978-1-119-48208-6.
  • Chan, E. Quantitative Trading: How to Build Your Own Algorithmic Trading Business, Ch. 6 (Money and Risk Management). Wiley, 2009. ISBN: 978-0-470-28488-9.
  • Carver, R. Smart Portfolios: A Practical Guide to Building and Maintaining Intelligent Investment Portfolios. Harriman House, 2017. ISBN: 978-0-85719-768-9.