Production-Research Parity

A strategy backtests beautifully in a research notebook: a Sharpe of 1.9, smooth equity curve, drawdowns well within tolerance. It's then reimplemented — often by a different engineer, in a different codebase, using a different library for handling timestamps and a slightly different rule for what counts as a valid trading day — for the live trading system. The live version loses money in its first month. Nothing about the market changed; the strategy's edge wasn't wrong. What changed is that the research code and the production code were never actually the same code, just two implementations of the same idea, and the differences between them — small, individually reasonable-looking — added up to a materially different strategy.

Production-research parity is the degree to which the environment and code used in research match what actually runs in production: same library versions, same handling of corporate actions and missing data, same timezone conventions, ideally the same functions, not two hand-written versions of the same logic maintained separately. Low parity means every backtest number carries an unstated asterisk — "this is what the idea would have done, assuming an implementation gap that nobody has quantified doesn't matter." High parity means a backtest number is a much more literal statement about what the live system will do, because it's closer to being the same system, not a lookalike of it.

Worked example. A research notebook computes daily returns using close-to-close prices, silently drops any day where a price is missing, and treats stock splits by dividing all prior prices by the split ratio. The production system, written separately months later by an engineer who wasn't shown the research code, uses adjusted prices from a different data vendor with a different (and undocumented) split-adjustment convention, and instead of dropping missing-price days, forward-fills the last known price. Individually each choice is defensible. Together, on a strategy sensitive to exact return magnitudes around corporate actions, they produce a live P&L path that diverges meaningfully from the backtest — not because the signal was wrong, but because "the signal" was never actually the same calculation in both places. Achieving parity here means the production system calling the same data-cleaning and return-calculation functions the research notebook used, not a re-implementation of them.

What this means in practice

The gap between research and production is one of the most underrated sources of live underperformance relative to a backtest, precisely because it doesn't announce itself as a bug — everything runs, nothing crashes, the numbers are just quietly different. Shared code libraries between research and production, pinned dependencies, and identical data-handling conventions close this gap; keeping research in notebooks and production in a rewritten codebase widens it. Paper trading and shadow mode exist partly to catch parity gaps empirically, by running the production system and comparing it directly against expectations, before it risks real capital.