Quant Memo
Core

Blind Reimplementation from Spec

Having a second researcher rebuild a strategy from its written description alone, with no access to the original code, to check whether the strategy's logic is really reproducible or whether the result depends on undocumented implementation choices.

A strategy that only works when run through one specific piece of code, written by one specific researcher, is a strategy whose apparent edge might live in undocumented details of that code rather than in the strategy's actual logic — an off-by-one in a lookback window, a particular way of handling missing data, a rounding convention that happens to avoid a bad trade. Blind reimplementation from spec is a check for this: a second researcher, who has never seen the original code, reads only a written specification of the strategy and builds it from scratch, and the two independent implementations are then compared.

The idea

The original researcher writes a specification describing the strategy in the same terms you'd use to explain it to a colleague — the signal, the entry and exit rules, the position sizing, the universe — without showing any code. A second person, with no access to the original implementation, builds the strategy from that spec alone and runs it on the same data. If the two implementations produce materially different results, the gap reveals which details were left ambiguous in the spec, and by extension, which details of the original code were secretly load-bearing for its performance.

This is different from simple code review: code review checks that an implementation matches its stated intent, but it can't catch cases where the intent itself was underspecified and the original author's arbitrary implementation choice happened to be the one that worked. Blind reimplementation forces every ambiguity in the spec to surface as a concrete disagreement between two working systems.

Worked example

A researcher specifies a strategy as "go long the top decile of stocks by 12-month momentum, rebalanced monthly, excluding the most recent month." A second researcher implements this from the spec alone and gets a Sharpe ratio of 0.4, well below the original's reported 0.9. Comparing the two implementations line by line reveals the gap: the original computed the 12-month return using month-end closing prices with dividends reinvested, while the reimplementation used raw prices without dividend adjustment, and the original also broke decile ties by market capitalization while the reimplementation broke them alphabetically by ticker. Neither of those choices was in the written spec — they were implicit in the original code. Once both are aligned, the reimplementation's Sharpe ratio matches within noise, and the spec is rewritten to make both choices explicit for anyone reimplementing it in the future.

What this means in practice

This process is most valuable exactly where it's most annoying to run: strategies with many small implementation details (data cleaning steps, tie-breaking rules, rebalance timing) where a plausible-sounding one-line description hides a dozen choices that could each shift the result. Firms that require blind reimplementation before allocating capital to a strategy are, in effect, requiring proof that the edge lives in the idea rather than in one person's code — a strategy that survives an independent rebuild from spec is much less likely to quietly break when someone else has to maintain or extend it later.

Blind reimplementation from spec has a second researcher rebuild a strategy from its written description alone, with no access to the original code — disagreements between the two implementations expose exactly which unstated implementation details the original result secretly depended on.

Related concepts

Further reading

  • Ioannidis, 'Why Most Published Research Findings Are False', PLoS Medicine
ShareTwitterLinkedIn