2.8 KiB
Change Management and Release Policy
Objective
The trading system must distinguish research changes from production changes. A profitable backtest is not sufficient to justify live rollout. This policy defines how code, configuration, prompts, schemas, and model versions move from idea to production.
Change Categories
Category 1 — Non-functional
Examples:
- logging changes
- dashboard text
- documentation updates
- internal refactoring with no output impact
Approval:
- engineering review
- no strategy re-approval required
Category 2 — Operational Functional
Examples:
- adapter retry policy
- alert routing
- improved reconciliation diagnostics
- performance optimization with no intended decision change
Approval:
- engineering review
- operations review
- replay validation required
Category 3 — Decision-Adjacent
Examples:
- parser prompt changes
- feature computation changes
- entity mapping changes
- attention overlay changes
- fill model parameter changes in backtester
Approval:
- engineering review
- strategy review
- replay and shadow-run evidence required
- release note must include expected behavioral impact
Category 4 — Strategy Material
Examples:
- entry/exit logic change
- risk cap change
- new data source enabling live gating
- model reranking rule change
- holding period change
Approval:
- engineering review
- strategy owner approval
- risk approval
- fresh backtest and walk-forward evidence
- paper or shadow validation window unless emergency exception
Required Evidence by Change Type
Every change request must include:
- summary of intent
- affected components
- risk classification
- expected behavior changes
- test evidence
- replay or shadow-run evidence where applicable
- rollback plan
- approver list
Prompt and Schema Changes
Prompt version, parser schema version, and output contract changes must be treated as decision-adjacent or strategy-material depending on impact. They may not be edited directly in production without review.
Emergency Release Rules
Emergency releases are allowed only to reduce risk or restore safe operation. Requirements:
- declare incident id
- minimize scope
- execute rollback-ready patch
- perform post-incident review within one business day
- do not include opportunistic unrelated improvements
Release Artifacts
Every release must generate:
- release id
- code commit/build id
- config hash
- migration record if any
- validation report link
- operator acknowledgement
Canary / Shadow Rules
Before broad activation, decision-adjacent and strategy-material changes should run in one or more of:
- replay validation
- paper trading shadow mode
- candidate diff mode against current production
Diff metrics to compare:
- candidate count change
- rank order change
- rejection rate change
- order count change
- expected exposure change
- attribution by feature family