The test that matters for any strategy going into production is not the Sharpe. It is whether a second analyst, handed the specification and nothing else, can rebuild the thing and land inside a tolerance band you agreed before they started. Most research that fails this fails not because the idea is weak but because the specification was never written to be executed by someone who was not in the room.
Run the rebuild once and the gaps are obvious. The second analyst comes back with a result 300 basis points a year apart from yours, and the reconciliation takes three days and ends in a disagreement about how a corporate action was handled. That reconciliation is the actual product of the exercise. The spec fields below are what that process converges on.
Set the tolerance band before the rebuild, not after
Agree in advance what counts as a successful reproduction, in writing, because after the fact everyone negotiates. A workable standard is agreement on trade-level identity rather than on returns: at least 95 percent of trades matching on symbol and entry date, and any return difference explainable line by line from the trades that did not match.
Returns-level tolerance alone is not enough, since two different implementations can land at similar annualised numbers through offsetting errors. Trade identity catches that. It also converts a vague disagreement into a finite list of rows to argue about, which is the difference between a three-day reconciliation and a three-week one.
The seven fields the specification has to pin
Everything else is commentary. If any of these is missing the rebuild will diverge and the divergence will be untraceable.
- Data source and vintage. Not "daily bars" but the specific vendor, the specific field, the adjustment convention for splits and dividends, and the date the extract was pulled. Vendors restate history. A rebuild against a later extract is testing a different world.
- Timestamp convention. Which timezone, which session boundary, whether a daily bar is stamped at open or close, and for crypto where the day is cut. This gets its own section below because it is where most reproductions die.
- Universe rule, evaluated point in time. The rule, the rebalance frequency, and crucially the as-of date the membership was determined on.
- Signal definition with every parameter value. Including the ones that felt like defaults. Window lengths, smoothing, the treatment of missing observations, and the minimum history required before an instrument becomes eligible.
- Cost model. Fees and slippage expressed in basis points round trip, plus whatever size dependence you applied, plus borrow and funding where relevant.
- Execution assumption. Which bar the fill lands on, at what price, with what participation limit, and what happens when the intended size exceeds it.
- Random seed and any ordering dependence. Anything involving sampling, tie-breaking, or partial fills has an ordering. Pin it or the rebuild cannot be bit-identical even when it is conceptually correct.
Timestamp convention is where the reconciliation goes
Two implementations of the same idea diverge most often on the alignment of the signal to the bar and the bar to the calendar. The usual suspects are worth listing because they recur.
Session boundaries first. Crypto has no close, so somebody chose one, and midnight UTC and 5pm New York produce measurably different daily bars, different signal values, and different trade dates. Equities have an official close and a consolidated tape that settles later, and a signal built from a print captured at 4:00:00 is not the same as one built from the official close published afterwards.
Then adjustment. A price series adjusted for splits and dividends as of today is a different series from the one that existed at the time, and any rule with an absolute price threshold in it will fire on different dates depending on which you used. State whether your series is total return or price only, and whether adjustment factors were applied retroactively.
Then restatement and point in time. Fundamentals get restated, index membership gets revised, and vendor histories get backfilled. If the spec does not say the extract date, a rebuild in six months is reading data your original test could not have seen. Store the extract itself, or a hash of it, next to the specification.
Specify the search space, not only the winning parameters
This is the field most specifications omit and the one a reviewer should ask for first. Reporting the parameter set that won tells the reader nothing about how many were tried.
The scale is easy to underestimate. Strategy Lab publishes the parameter count for each template on the setup screen: the momentum EMA cross template shows 64 params, mean reversion on RSI bounds shows 60, the N-day breakout 24, and the Donchian channel 20. A sweep across a space that size and a single hand-picked configuration are entirely different claims about the evidence, and only one of them is reproducible from a spec that lists final values.
So the spec records the grid that was searched, the selection criterion used to pick the winner, and the number of configurations evaluated. It also records the holdout policy: which period was reserved, when it was unsealed, and whether it was looked at more than once. A holdout consulted three times is not a holdout, and if that happened the spec should say so rather than hide it.
The same discipline applies to the test window itself. Lab exposes fixed period options from 3mo through 5y along with fee and slippage inputs in basis points and a pre-screen that drops illiquid, stablecoin and wrapped instruments. Every one of those is a choice that shapes the result, and each needs to appear in the spec as a stated value rather than as whatever the screen happened to be set to.
Where the specification lives and what a reviewer opens first
Keep the spec versioned in the same repository as the research, not in a document store, and give it a hash that is recorded alongside every result you circulate. A chart in a deck with no spec hash on it should not be usable in a decision, and the way to make that stick is to require the hash on the slide.
Pin the config to the code that ran it. The saved strategy object in the Builder is a live thing, editable, and the version that produced the number in your memo may not be the version sitting there when the reviewer opens it. Export the configuration at the time you produce a result and store it with the result. A strategy whose returns you can quote but whose exact configuration on that date you cannot retrieve is not evidence.
When I review someone else's work the order is fixed. Extract date and universe as-of date first, because those two determine whether the whole thing is contaminated. Then execution assumption and cost model, because they determine whether the edge survives contact with the desk. Then the search space, because it determines how much of the result is selection. The signal definition itself comes last, which surprises people, but the signal is rarely where the problem is.
Two adjacent habits make the difference between a spec that works and one that only looks complete. Write it before the final run rather than after, so it describes the intended experiment instead of the one you happen to have got. And have the rebuild done by someone who did not help build it, because a colleague who was in the design conversations will unconsciously fill in the missing fields with what they already know, which is precisely the failure the exercise exists to detect.