Skip to content

Last Updated: 2026-05-03 Owner: Ops-Dev Summary: Tactical checklist for validating, shipping, and watching any meaningful release change in QuantMatrix.

QuantMatrix Release Change Checklist

This checklist is for individual releases and change sets.

Its purpose is to make sure every meaningful change is reviewed for: - scope - safety - operational impact - rollback readiness - test coverage

Use this for: - feature releases - bug fixes - strategy changes - broker integration changes - risk rule changes - UI behavior changes - analytics changes - schema and migration changes

This checklist is intentionally lighter than the full Production Readiness Review, but it should still be treated seriously.

1. Change Metadata

  • Change Title:
  • Release / Version:
  • Date:
  • Owner:
  • Target Environment: Local / Paper / Live / All
  • Change Type:
  • Feature
  • Bug Fix
  • Strategy Change
  • Risk Change
  • Broker Change
  • UI Change
  • Analytics Change
  • Schema Change

2. Change Summary

  • What is changing:
  • Why it is changing:
  • Modules affected:
  • User/operator-visible impact:
  • Hidden system impact:

3. Scope Check

  • [ ] Change scope is clearly defined
  • [ ] Out-of-scope items are identified
  • [ ] Dependencies are known
  • [ ] Downstream modules affected are identified
  • [ ] No unrelated refactor is mixed in without reason

4. Safety Check

  • [ ] Change cannot bypass risk controls
  • [ ] Change cannot place orders outside intended flow
  • [ ] Live vs paper behavior remains clearly separated
  • [ ] Dangerous defaults were not introduced
  • [ ] Manual override behavior is still safe

If change affects trading decisions directly: - [ ] Entry behavior reviewed - [ ] Exit behavior reviewed - [ ] Sizing behavior reviewed - [ ] Duplicate-order protection reviewed

5. Data and State Check

  • [ ] State transitions still make sense
  • [ ] Persistence impact reviewed
  • [ ] Redis key changes reviewed
  • [ ] Database schema changes reviewed
  • [ ] Migration impact understood
  • [ ] Reconciliation impact reviewed
  • [ ] Analytics capture impact reviewed

6. Operational Impact Check

  • [ ] Startup behavior reviewed
  • [ ] Shutdown behavior reviewed
  • [ ] Health checks updated if needed
  • [ ] Alerts updated if needed
  • [ ] Runbook impact reviewed
  • [ ] Incident playbook impact reviewed

7. UI and Operator Check

  • [ ] Operator-facing labels remain clear
  • [ ] Trading mode remains visible if relevant
  • [ ] Critical controls remain accessible
  • [ ] Errors remain understandable
  • [ ] No misleading status indicators introduced

8. Testing Check

Automated

  • [ ] Unit tests added or updated
  • [ ] Integration tests added or updated
  • [ ] Existing tests pass

Manual

  • [ ] Core flow tested manually
  • [ ] Failure path tested if relevant
  • [ ] UI tested if relevant
  • [ ] Paper trading validation done if required

Gaps

  • Known untested areas:
  • Why acceptable:

9. Rollback Check

  • [ ] Rollback approach documented
  • [ ] Schema rollback risk understood
  • [ ] Config rollback risk understood
  • [ ] Feature flag or safe disable path exists if needed
  • [ ] Operator knows how to revert safely

10. Deployment Check

  • [ ] Deployment steps understood
  • [ ] Order of deployment reviewed
  • [ ] Required env var changes reviewed
  • [ ] Required migrations reviewed
  • [ ] Required restart behavior reviewed

11. Monitoring Check

  • [ ] Logs added or updated where needed
  • [ ] Metrics added or updated where needed
  • [ ] Alerts added or updated where needed
  • [ ] Success criteria observable after release

12. Post-Release Watch Items

After release, watch: - [ ] broker connectivity - [ ] order behavior - [ ] positions behavior - [ ] risk blocks - [ ] UI state accuracy - [ ] analytics integrity

Specific watch notes:

-

13. Approval

  • Ready to release: Yes / No / Yes with restrictions
  • Restrictions if any:
  • Reviewer:
  • Approval time:
  • Notes:

14. Follow-Up Items

  • [ ]
  • [ ]
  • [ ]