Change Management Policy

1. Purpose

Ensures changes to production code and infrastructure are reviewed, tested, and traceable.

2. Scope

All code and infrastructure changes that can affect production systems or production data. Includes application code, IaC (SST/Pulumi), SaaS configuration, and IAM policies.

3. Policy statements

3.1 Source control

1. All code lives in GitHub under the New-Horizon-Technology organization.
2. master is the production branch. Direct pushes to master are prohibited by branch protection.

3.2 Pull requests

1. Every change reaches master via a pull request.
2. Every PR requires:
   • At least one reviewer approval (the CEO is an allowed reviewer; a second engineer is preferred when one is available).
   • Passing CI (TypeScript build, ESLint, unit tests).
3. PR description documents: what changed, why, how tested, any risk or rollback plan.

3.3 Emergency changes

1. An emergency change (hotfix for outage) may be merged by the CEO with a retroactive PR review within 24 business hours.
2. Every emergency change is filed in the audit log with action=change.emergency and the justification.

3.4 Infrastructure

1. IaC changes go through the same PR process. Preview plans (pulumi preview) are attached to the PR.
2. AWS console changes outside IaC are prohibited except for diagnostics. If a console change is required to resolve an incident, it is reconciled back into IaC within 5 business days.

3.5 Releases

1. Every push to master auto-deploys via SST.
2. Releases are tagged v-YYYY.MM.DD.N and reachable via a rollback.
3. A CHANGELOG.md entry is required for changes that materially affect security, privacy, data handling, or customer-facing behavior.

3.6 Rollback

1. Every release has a documented rollback path (git revert + redeploy, or IaC stack downgrade).
2. Rollbacks ≤ 1 hour from decision are the standard.

4. Roles & responsibilities

Role	Responsibility
Engineering	Writes PRs, reviews PRs, owns rollback plans.
Security Officer	Reviews security-sensitive changes (IAM, secrets, auth).
CEO	Approves emergency changes; owns release authority.

5. Enforcement & exceptions

Direct pushes to master are blocked by branch protection. Branch protection is managed by the Security Officer and cannot be disabled without CEO approval, tracked in the audit log.

6. References

• 016-secure-software-development-policy.md
• 018-vulnerability-management-policy.md

7. Revision history

Version	Date	Author	Approver	Change
1.0	2026-04-17	S.O.	CEO	Initial policy

Approval

This policy has been reviewed and is hereby approved for the named version and effective date above.

Approved by	Myles Bai
Title	Chief Executive Officer, Rex Black LLC
Email	myles@rexblack.com
Approval date	2026-04-17
Effective date	2026-04-17
Next review due	2027-04-17

Digital signature of record: the CEO's electronic approval is captured in the platform audit log (event kind admin.policy.approved) with hash-chained integrity under the M-C1 control. The hash-chained audit log entry for this document is the canonical signature of record; this printed block exists for print/review convenience.