Versioning and Re-Fitting a Live Strategy

When a live strategy gets re-fit — new parameters, an updated universe, a reworked signal — the temptation is to simply push the change and move on, treating it as an improvement to the same ongoing strategy. This is a mistake, because it silently erases the ability to answer two questions that matter a great deal later: which version of the strategy actually produced last month's P&L, and what would have happened if the change had never been made. Versioning a live strategy means treating each material change the way software engineers treat a code release — tagged, dated, documented, and reversible — rather than as an invisible in-place edit.

In practice this means every re-fit gets a version number and a change log entry: what changed, why, what the backtested impact of the change was expected to be, and who approved it. P&L and risk attribution are then tracked per version, not just per strategy name, so that a manager reviewing three months of performance can see "1.2 months under v3.1, 2 months under v3.2" rather than one blended number that hides whether the re-fit actually helped. Just as importantly, the previous version's code and parameters are kept, not overwritten, so that if the new version underperforms, the firm can roll back to the exact configuration that was running before — rather than trying to reconstruct it from memory or documentation that may be incomplete.

A concrete case: a trend-following strategy is re-fit to shorten its lookback window after a review attributes recent underperformance to a changed volatility regime. The change is tagged v4.0, the previous v3.4 configuration is archived rather than deleted, and both are entered into the daily monitoring dashboard so their performance can be tracked separately going forward. Two months later v4.0 is underperforming even the diagnosed problem it was meant to fix. Because v3.4 was preserved rather than overwritten, the firm can roll back cleanly to a known, previously-validated configuration the same day, rather than needing to re-derive it or accept the new version's problems while a fresh fix is built from scratch.

What this means in practice

Versioning matters most exactly when things go wrong, which is also when it's most tempting to have skipped it — under time pressure, "just fix it and redeploy" feels faster than "tag it, log it, archive the old version first." The discipline pays for itself the first time a re-fit doesn't work as hoped and a clean rollback, rather than a scramble, is what's needed.