Strategy drift: change rules outside live risk

The short answer

Give every active strategy a version with explicit setup, evidence, entry, size, route, cost, exit, and review rules. Freeze that version when a trade is opened. Propose changes in a separate review record with a hypothesis, affected sample, risk analysis, test, acceptance rule, effective time, and rollback condition.

An exception made to protect capital from a new security or operational threat is not permission to silently redefine the strategy. Execute the breach or emergency rule, preserve what changed, and decide later whether a new version should exist.

Know what counts as a strategy change

Version the setup definition, asset universe, chain, venue, time window, evidence sources, data transformations, thresholds, entry trigger, position sizing, liquidity minimum, route, slippage, fees, order behavior, invalidation, targets, holding period, partial exits, session rules, and review denominator.

Operational settings can change economic behavior. A new RPC, aggregator, terminal default, priority fee, quote source, token filter, alert delay, or wallet permission may deserve a version even when the written thesis is unchanged. Record the effect, not just the label “minor.”

Adaptation and drift are not opposites

CME describes a trade plan as a working document whose assumptions about costs, revenue, and business conditions may be right or wrong. Updating a plan is expected. Controlled adaptation makes the change visible, testable, attributable, and reversible; drift makes the rules depend on the current outcome.

Define who may propose and approve a change, the scheduled review that can activate it, and whether open positions remain governed by the prior version. A strategy is not “adaptive” merely because its rules can be explained after each trade.

Freeze the governing record before entry

Save the strategy ID and version, effective time, exact rule text, configuration, source definitions, expected costs, and any allowed discretionary fields. Attach that version to the trade before signing. Later edits must create a new record instead of overwriting the one the trade used.

The trade-specific journal record should capture inputs and choices, while the strategy version defines how those inputs create permission. Store enough detail to reconstruct both without relying on the current interface or memory.

Separate exceptions, incidents, and new versions

• Planned discretion: a field and its allowed range already exist in the active version; the trader records the selected value and reason.
• Rule breach: the trader acts outside the version without prior permission; the breach remains visible even if the trade wins.
• Security or operational incident: unexpected wallet, token, route, venue, or data risk invokes a prepared protection procedure.
• Proposed strategy change: a future version is evaluated outside the live position and receives its own evidence and approval.

Do not backdate a new version to make a breach compliant. The incident can reveal a missing contingency, but the new rule begins only at its documented effective time.

Write a change proposal before testing it

State the observation, affected version and cohort, proposed rule difference, mechanism by which it may help, expected benefit, added failure modes, data required, test window, sample rule, acceptance threshold, maximum test loss, approver, rollout scope, and rollback trigger.

Record alternatives and the option to make no change. If several inputs must change together, name the bundle; otherwise isolate changes so the result can be attributed. A proposal that changes entry, size, and exit simultaneously should not claim to know which component caused the outcome.

Protect the test from outcome leakage

Fix inclusion rules before inspecting the result. Include every qualifying opportunity, failed transaction, partial fill, no-trade, residual position, and full cost. Keep live, simulated, backtested, and reconstructed observations separate, and preserve data that was actually available at decision time.

Use the review-habits guide to distinguish a repeated pattern from one memorable outcome. A small sample can justify continued observation or a conservative test; it does not become reliable because the latest result is emotionally persuasive.

Stage deployment and bound its damage

Depending on what the change affects, progression may include offline reconstruction, forward observation without orders, simulation, a restricted wallet, reduced size, limited assets or sessions, and finally the approved scope. Each stage needs a maximum loss, security boundary, evidence requirement, and stop rule.

Simulation cannot reproduce every fill, latency, liquidity, signing, or behavioral effect. Label what the stage tests and what remains untested. A technical feature working once does not validate its economic assumptions.

Version the executable configuration

Store machine-readable settings when possible: network and program identifiers, token filters, data-provider and schema versions, thresholds, fee rules, route allowlists, slippage, order expiry, wallet role, alert behavior, and feature flags. Save a hash or immutable snapshot alongside human-readable notes.

Record defaults supplied by the terminal and which values were inherited. A UI update can alter routing or protection without changing the strategy document. Re-verify the effective configuration before the first trade after an update.

Rollback is a decision made before failure

Define the performance, execution, data, security, or operational event that stops the new version; who can disable it; how new entries are blocked; how open positions are governed; and which known-good configuration is restored. Test the rollback path before relying on it.

Preserve failed versions and their records. Reusing an old name for new rules destroys attribution, while deleting losing tests encourages the same idea to return without its history.

Do not mix active versions invisibly

If two versions run at once, assign opportunities before outcomes are known and give each separate capital, risk, configuration, and review records. Define how conflicts are resolved when both qualify for the same asset or share an account, venue, or liquidity path.

A portfolio can inherit concentration and operational risk across strategies. Version-level limits do not replace the total open-risk and position-sizing controls.

A strategy-change workflow

1. Freeze the active version. Save rules, configuration, sources, scope, effective time, and owner before the next trade.
2. Classify the event. Distinguish planned discretion, breach, incident, and proposed change without backdating.
3. Write the proposal. State evidence, mechanism, difference, risks, test, acceptance rule, rollout, and rollback.
4. Protect the sample. Fix the denominator and information set, then retain failures, no-trades, costs, and residuals.
5. Stage the rollout. Bound capital, assets, sessions, permissions, and duration at every test stage.
6. Activate visibly. Assign a new version and effective time, verify configuration, monitor, and preserve the prior rollback target.

What belongs in the journal

Record strategy ID and version, owner, rule and configuration snapshot, effective time, trade-to-version assignment, planned discretion, breaches and incidents, change observation and cohort, hypothesis, exact difference, alternatives, risk analysis, test data and denominator, maximum test loss, acceptance threshold, approvals, rollout stages, actual results, configuration verification, stop event, rollback, deprecation, and unresolved questions.

Primary and official sources