Change Control for Live Strategies

A strategy that's been running live for a year and made money the whole time still needs to change — a parameter gets recalibrated, a data feed gets swapped for a cleaner one, a bug in the fill-cost estimate gets fixed. The dangerous part isn't making the change; it's making it the same casual way a researcher edits a backtest script on their laptop, and pushing it straight to a system trading real capital. Change control is the process that stands between "the researcher thinks this is an improvement" and "this is now live."

A workable process has a few non-negotiable steps. First, the change is described in writing — what's changing, why, and what the expected effect on the strategy's behavior is. Second, someone other than the person who made the change reviews it: a second set of eyes catches the sign error or off-by-one that the author, having stared at the same code for hours, no longer sees. Third, the change is tested somewhere that isn't production — a paper-trading environment or a shadow deployment that runs in parallel with the live strategy without actually sending orders. Fourth, the deployment itself is logged: who approved it, when it went live, and what the previous version was, so it can be rolled back quickly if something goes wrong.

That last point matters more than it sounds. The single most useful thing a change-control process buys a firm during an incident is a fast, confident rollback. If a change goes live at 9:31am and the strategy starts behaving strangely at 9:45, the question isn't "what's wrong with the model" — it's "what changed, and can we put the previous version back right now." A firm without change control has to reconstruct that history from memory and scattered files, usually under pressure, usually slowly. A firm with it can revert in minutes because the previous version and the deployment record are both sitting right there.

The level of process should scale with the risk tier of the strategy, not be applied uniformly. A tier-1 strategy trading a large book might require sign-off from risk management and a mandatory shadow-run period before any change goes live; a small experimental sleeve might only need a second reviewer and a logged commit. What should never scale down to zero, at any tier, is the basic discipline of a second reviewer and a record of what changed.