Strategy versioning is the practice of assigning a unique identifier to each distinct set of strategy rules.
Strategy versioning is the practice of assigning a unique identifier to each distinct set of strategy rules. When a rule changes, the strategy version changes with it. This creates a direct link between a reported result and the exact configuration that produced it.
The mechanism is straightforward. A research process moves from idea to specification, then to implementation, testing, review, and publication. Sonar describes this path as a sequence that begins with research notes and proceeds through codified rules, validation, and release. In that workflow, versioning gives each rule set a stable reference point across stages. A result is not attached to a vague strategy name. It is attached to a specific version of the rules used in the test or audit record. That reduces ambiguity when multiple iterations exist at the same time.
Versioning matters because quantitative research is iterative. Parameters, filters, execution assumptions, and data handling rules often change during development. Without explicit version numbers, a later result can be confused with an earlier rule set, or an earlier report can be interpreted as if it came from current logic. Numbering each version prevents that conflation by making rule changes explicit and traceable.
This also improves auditability. Sonar’s backtest overfitting audit framework focuses on examining whether apparent performance may be explained by repeated trials and selection effects rather than durable signal. That kind of audit depends on knowing what was tested and in what form. If each rule change is versioned, the audit trail can distinguish one tested specification from another. The record can then show which metrics belong to which version instead of pooling outcomes from different configurations into a single unlabeled history.
The same logic applies to published performance statistics. Sonar’s glossary entry on the deflated Sharpe ratio explains that standard performance measures can be misleading when many variants are tried and only the best result is highlighted. A versioning scheme helps preserve the mapping between each tested variant and its measured statistics. That does not by itself solve selection bias, but it provides the bookkeeping needed to evaluate results in context and apply tools such as overfitting audits or deflated performance measures to the correct strategy instance.
A systematic versioning scheme can be simple. Each material change to the rule set receives a new version identifier. The identifier is stored with the rule specification, code snapshot, test configuration, and output metrics. If version 1.2 adds a volatility filter, then any backtest, audit artifact, or report generated under that logic is labeled version 1.2. If version 1.3 changes position sizing or entry timing, new results are labeled version 1.3, not merged into the prior record. This lets a researcher compare versions cleanly and lets reviewers verify that a published metric belongs to the stated configuration.
In practical terms, versioning supports three controls. First, attribution control. Every chart, table, and metric can be tied to a specific rule set. Second, change control. Reviewers can see what changed between versions rather than infer it from code differences alone. Third, audit control. When a result is questioned, the team can reproduce the exact version under review and separate it from adjacent experiments.
Covered in depth in the From research to publishing pillar hub.