Who this is for — Anyone who must turn an idea into rules that another person or program can implement, test and monitor without guessing the author's intentions.
A systematic strategy specification is the versioned document that describes a strategy before evaluation: purpose, hypothesis, permitted information, transformations, signals, positions, risk, orders, costs, benchmark, controls and review criteria. It is simultaneously a research contract, an interface between research and production, and an audit trail.
A sentence such as “buy the breakout on volume” is not a specification. It leaves the universe, calendar, adjustments, window length, inclusion of the current bar, calculation time, first executable price, size, exit, gap handling and missing-data behaviour undefined. Every ambiguity allows the backtest to embed retrospective decisions that would not have been available in real time.
Minimum building blocks
| Block | Verifiable content | Review question |
|---|---|---|
| Purpose and intended use | supported decision, users, frequency and limitations | what must the system not do? |
| Hypothesis | mechanism, falsifiable prediction, failure conditions | what alternative explains the same result? |
| Universe | inclusion, exclusion, historical membership and effective date | does it contain only current survivors? |
| Data | source, field, timestamp, time zone, lag, revision and version | was the value knowable at decision time? |
| Signal | formula, window, state, missing-data behaviour and event order | are any branches undetermined? |
| Portfolio | signal-to-position mapping, constraints, netting and rebalancing | which exposure actually dominates? |
| Risk | limits, scenarios, sizing, escalation and fail-safe behaviour | what happens when an input or limit fails? |
| Execution | order type, venue, timing, fill, borrow, funding and costs | was the simulated price attainable? |
| Evaluation | benchmark, metrics, splits, attempts and decision criterion | can the final test influence selection? |
| Monitoring | owner, justified thresholds, alerts, suspension and rollback | who decides, and using what evidence? |
The fields may live in prose, configuration and code, provided they can be reconciled. Units must be explicit: percentage of capital, notional, volatility, delta, currency and frequency are not interchangeable.
The causal clock
The specification must order at least four moments:
information available → signal computed → order submitted → fill possible“Daily closing price” is not enough. The official close may be known only after the auction; a fundamental may refer to a quarter but become public weeks later; a macroeconomic series may be revised. If the signal uses the close and the backtest buys at that same close, an explicit mechanism must make auction participation possible with the required information. Without that mechanism, the first subsequent price is a more coherent choice, but it too must model gaps and costs.
For each input, at least three dates are useful: the economic reference period, initial publication and the version or vintage used. Each order needs a state, timestamp, requested quantity, executed quantity, price and reason for rejection or cancellation.
States and exceptions
A real strategy does not live only in the “signal present → order filled” branch. The specification establishes what happens when:
- data are missing or arrive late;
- an instrument is suspended, delisted or changes identifier;
- a futures contract enters its roll window;
- stock borrow is unavailable or its cost exceeds the limit;
- an order is partially filled, rejected or remains open at session end;
- price, position, margin or P&L does not reconcile;
- a risk control or broker connection stops responding.
“Do nothing” is a valid rule only when the resulting state is specified: keeping the previous position, reducing it, liquidating it or blocking new orders creates different risks.
Connected research protocol
Before observing the outcome intended to support a decision, the protocol records:
- the question and falsifiable hypothesis;
- the specification version and code repository;
- dataset, time perimeter and universe;
- coherent baseline and benchmark;
- primary and secondary metrics, gross and net;
- in-sample, validation and final-test design;
- the set of candidate parameters or models;
- cost, liquidity and capacity assumptions;
- the criterion for continuing, modifying or rejecting the strategy;
- a ledger of every attempt, including negative results.
A criterion need not be a single threshold. It may require economic coherence, a stable sign across segments, acceptable uncertainty, net materiality and no dependence on one datapoint or variant. The choice should match the use: an internal exploratory tool and a strategy deploying capital have different consequences.
Versions, reproducibility and replication
Every result should identify the code commit or release, configuration file, environment and dependencies, random seeds, dataset version and output. A snapshot or hash helps demonstrate that the input has not changed. Running the same code again on the same data concerns reproducibility; obtaining consistent evidence from an independent realisation concerns replication. The two properties are related but not equivalent.
When an out-of-sample test prompts a modification, a new version begins. The segment already inspected does not become uncontaminated again: it must be recorded as development information. This genealogy prevents successive iterations from accumulating invisible data snooping.
Separating roles can make review more effective, but “independent” does not necessarily mean external. It means that the person challenging assumptions, implementation and use has the expertise, authority and incentives to dispute the result.
Illustrative example: an end-of-day signal
A hypothetical specification states that the signal uses only data
consolidated through the close of t; it is computed after the final files are
received; orders may be submitted no earlier than the open of t+1. The
universe is reconstructed from historical membership; non-tradable instruments
create an exception state; size respects participation and concentration
limits; cost depends on spread and quantity.
The example does not prescribe the next open as universally correct. It shows how to make causality controllable. A strategy participating in the closing auction would instead require signals computable before the cutoff and an execution model consistent with that auction.
Quality criteria
- An independent implementer must not have to invent a missing rule.
- Every variable has a definition, unit, timestamp and missing-data behaviour.
- Results can be traced to an immutable version.
- Backtest and production assumptions can be compared line by line.
- Exceptions lead to safe and observable states.
- Limits are tied to risk, capacity or intended use, not decorative numbers.
- Every material change reopens the relevant checks.
The specification does not eliminate model risk. It does, however, expose the choices and make it possible to distinguish a research error from an implementation or use error.
Sources
- Joseph Simonian, CFA Institute Research Foundation, Investment Model Validation: A Guide for Practitioners — purpose, validation techniques, benchmarking, stress and documentation.
- Federal Reserve, SR 26-2 — Revised Guidance on Model Risk Management — current principles for development, use, validation, governance and monitoring within supervised banking.
- U.S. Securities and Exchange Commission, Staff Report on Algorithmic Trading in U.S. Capital Markets — institutional context for decision and execution algorithms and their risks.
- National Futures Association, Interpretive Notice 9025 — Hypothetical Results — limitations of hypothetical results and the relevance of assumptions, liquidity, slippage and behaviour; application is limited to its own scope.