# 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