Change Management Policy

Document Info

Version: 2026.6 · Last Reviewed: 2026-02-18 · Classification: Internal · Owner: CTO View Source · Download PDF

1. Purpose

Defines requirements for managing changes to Meridian Seven production systems to minimize service disruption and maintain system integrity.

2. Scope

All changes to:

• Application source code (frontend, backend, agent services)
• Database schemas and migrations
• Infrastructure configuration (GCP Cloud Run, Supabase, Cloudflare)
• CI/CD pipelines and deployment workflows
• Environment variables and secrets (Doppler)
• Third-party integrations and dependencies
• Monitoring and alerting configurations

3. Environments

Environment	Branch	Purpose	URL
Development	dev	Integration testing, feature development	dev-navi.meridian7.io
Staging	staging	Pre-production validation, QA	staging-navi.meridian7.io
Production	main	Live customer-facing environment	navi.meridian7.io

Promotion chain: dev → staging → main

Changes must not skip environments. Direct pushes to production are prohibited except under the Emergency Change Process (Section 7).

4. Standard Change Process

4.1 Pull Request Requirements

Requirement	Detail
Description	Clear summary of what changed and why
GitHub issue link	Every change must reference a tracked GitHub issue
Code review	At least one approved review from a qualified reviewer
CI checks pass	All required status checks must pass before merge

4.2 CI/CD Pipeline Requirements

Check	Tool	Scope
Linting	ESLint (TypeScript), Ruff (Python)	Code style and quality
Type checking	TypeScript compiler, mypy	Type safety
Unit tests	Vitest (TypeScript), pytest (Python)	Functional correctness
Security scanning	Dependabot, Claude Security Review	Vulnerabilities and committed secrets
Build verification	Turborepo build	Compilation and bundling
Migration check	drizzle-kit check	Database migration chain integrity

All checks must pass before merge. No bypassing of required checks is permitted.

4.3 Deployment Approval

Stage	Approver	Method
PR merge to dev	Code reviewer (engineer)	GitHub PR approval
Promote dev → staging	CTO or designated lead	Manual after local verification
Promote staging → main	CTO	Manual after staging validation

4.4 Deployment Execution

• GCP Cloud Run deployments trigger automatically via Cloud Build on branch push
• Database migrations run as part of CI/CD gated by workflow_run
• All deployments logged with commit SHA, timestamp, and deployer

5. Rollback Procedures

5.1 Web Application (GCP Cloud Run)

1. GCP Console → Cloud Run → select service → Revisions → identify last known-good revision
2. Edit service → set traffic to 100% on the known-good revision
3. Verify via smoke tests and monitoring

5.2 Agent Service (GCP Cloud Run)

1. GCP Console → Cloud Run → select agent service → Revisions → rollback to previous revision
2. Verify via health check endpoint and monitoring

5.3 Database Migrations

Database migrations are forward-only. Rollback requires a new reverse migration. Supabase PITR is available as last resort.

5.4 Rollback Documentation

All rollbacks must record: reason, timestamp, affected systems, person who initiated, and a follow-up GitHub issue for root cause analysis.

6. Change Documentation Requirements

Every change must have:

1. GitHub issue — Purpose, scope, and acceptance criteria
2. Pull Request — Description, linked issue, and review history
3. Commit messages — Imperative subject lines referencing the GitHub issue
4. Deployment record — Automated via CI/CD (commit SHA, timestamp, environment)

7. Emergency Change Process

Permitted when an active SEV-1 or SEV-2 incident requires an immediate fix that cannot wait for the standard process.

7.1 Criteria

• Active production incident (SEV-1 or SEV-2) requiring immediate resolution
• Security vulnerability under active exploitation
• Data integrity issue requiring immediate correction

7.2 Procedure

1. Incident commander (CISO or CTO) authorizes the emergency change
2. Minimum requirements before deploying:
   • Automated CI checks pass (lint, type-check, build)
   • At least one other engineer reviews (synchronous/verbal acceptable)
3. Create a GitHub issue immediately if one does not exist

7.3 Post-Hoc Review

Within 24 hours of the emergency change, document:

• Justification for bypassing standard process
• The change made (PR link or commit SHA)
• Testing performed before and after deployment
• Any follow-up work needed

Attach to the incident postmortem if applicable.

8. Change Freeze Periods

• Declared by CTO during critical business periods
• Only emergency changes (Section 7) are permitted during a freeze
• Communicated at least 48 hours in advance via Slack #engineering

9. Automated Evidence Collection Exception

Automated evidence collection workflows commit directly to main without a pull request. This is an intentional exception to the standard change process because:

• Evidence workflows are read-only collectors — they query APIs and write JSON artifacts to evidence/ paths only
• Workflows use SHA-pinned GitHub Actions — no mutable version tags, preventing supply chain compromise
• All commits are made by github-actions[bot] — identifiable and auditable in git history
• Evidence artifacts include SHA-256 integrity manifests for tamper detection
• Evidence changes are reviewed during weekly security reviews (Risk Management Policy §6.2)
• Branch protection remains enforced for all other paths — only evidence workflows authenticate with GH_PAT_ADMIN

This exception is documented as a compensating control and reviewed annually.

10. Enforcement

Changes that bypass this policy without emergency authorization are policy violations subject to the disciplinary process in the Information Security Policy. CI/CD branch protection prevents most unauthorized changes automatically.

11. Related Documents

• Information Security Policy
• Incident Response Plan
• Backup and Recovery Policy

---

Meridian Seven — Confidential