How to document a trading strategy

A trading strategy becomes testable and reproducible when its specification fully defines the universe, rules, position sizing, transaction costs, and all assumptions. Sonar’s research workflow and audit materials support this principle by emphasizing formalized research, backtest auditing, and corrected evaluation metrics such as the deflated Sharpe ratio.

A trading strategy is testable when another analyst can recreate the same backtest from the written specification. In practice, that requires a complete description of what is traded, when trades are entered and exited, how positions are sized, what trading costs are applied, and what assumptions govern the test. If any of those elements are missing, the strategy description leaves room for interpretation, and different analysts may produce different results from the same idea.

A useful strategy specification starts with the universe. The universe defines the set of instruments that are eligible for selection and testing. Without a precise universe, a backtest can change materially because the sample of tradable assets changes. A specification should therefore state the asset class, the exact eligible instruments or inclusion criteria, any regional or exchange filters, and the time period over which those instruments are considered. The goal is to remove ambiguity about what the strategy is allowed to trade.

The next part is the rule set. Entry rules describe the conditions that open a position. Exit rules describe the conditions that close it. These rules need to be explicit enough that another analyst can code them without guessing. That means defining the inputs, thresholds, timing conventions, rebalance frequency, signal formation process, and any conflict-resolution logic when multiple signals occur at once. If a rule depends on rankings, ties, lookback windows, or delayed execution, those details belong in the specification because they affect the result.

Position sizing is a separate component and should be documented separately from the signal. A strategy can have the same entry and exit rules but produce different behavior depending on whether positions are equal weighted, volatility scaled, capped, or constrained by exposure limits. A specification should state how capital is allocated across positions, whether leverage is assumed, how cash is treated, and what happens when a sizing rule conflicts with a portfolio constraint. This is necessary because sizing determines how the signal is translated into portfolio weights.

Transaction costs and implementation assumptions also need to be stated directly. Backtests depend on assumptions about commissions, spreads, slippage, turnover effects, and execution timing. If these costs are omitted or vaguely described, a replication attempt may not match the original test. A complete specification therefore states the cost model used, when costs are applied, and any assumptions about liquidity or trade execution. The same principle applies to data handling assumptions such as rebalancing calendars, missing data treatment, and whether the test uses point in time inputs or revised data. These assumptions shape the realism and reproducibility of the test.

Sonar Sciences describes a research workflow that moves from idea generation to testing and publication, with an emphasis on making research inspectable and shareable. In that workflow, documentation is part of turning a research idea into something another person can evaluate. The published research process highlights that a strategy should be expressed clearly enough to be tested, audited, and communicated rather than kept as an informal concept. That supports the role of a full written specification in reproducible strategy research.

Sonar’s backtest overfitting audit tool provides a concrete mechanism for independent validation. The tool is designed to audit a backtest for signs of overfitting rather than simply accept reported metrics at face value. In that setting, a complete specification matters because an auditor needs the exact universe, rules, sizing method, cost assumptions, and test setup in order to reproduce the original backtest and then examine how robust it is. A strategy description that omits these elements is not fully auditable, because the auditor would need to infer missing implementation details.

The claim that a detailed specification makes a strategy reproducible is supported by the structure of Sonar’s research and audit materials, which emphasize formalized research, backtest auditing, and corrected evaluation metrics.

In practical terms, a complete strategy specification should answer five questions. What is the tradable universe. What exactly triggers entry and exit. How are positions sized and constrained. What costs and execution assumptions are applied. What other assumptions govern the data and test procedure. When those questions are answered precisely, another analyst can implement the same strategy logic, compare outputs, and assess the backtest with the same audit framework. That is what makes a strategy testable by someone else.

Drafted with AI assistance from cited sources. Reviewed and approved by Sonar Sciences Quant & Research Team.