Change Management Policy

1. Pre-merge checks

• Code review — every non-trivial code change is reviewed by a second party before merge. The reviewer evaluates correctness, security implications, schema impact, and adherence to the policies in this trust center.
• Adversarial review — for security-relevant or schema-relevant changes, an additional adversarial review pass is run (an independent model or engineer is asked to find what's wrong with the change before approving it).
• Lint and type checks — static analysis runs on every commit and blocks merge on failure.
• Pre-commit secret scanning — every commit is scanned for accidental introduction of credentials. Detected secrets block the commit until rotated and removed from history.
• Migration safety check — database migrations are validated for safe ordering, destructive-operation flagging, and presence of rollback instructions. Migrations marked destructive without a rollback or backup note are blocked.
• Test suites — relevant test suites run on every change. Failing tests block merge.

2. Deployment

• Production deployments are tagged commits applied through a documented procedure.
• Schema migrations apply ahead of the application changes that depend on them, in a forward-compatible order that supports a same-version rollback of application code if needed.
• Configuration changes (environment variables, third-party credentials) are applied via the same change management track as code; ad-hoc changes outside the documented procedure are not permitted.
• Service restarts use the supervised process manager's rolling reload to minimize disruption.
• Post-deploy smoke tests verify core paths (authentication, integration health, scheduled job liveness).

3. Emergency change

An emergency change (responding to a SEV1 / SEV2 incident, a critical vulnerability, or a customer-impacting outage) may bypass the normal pre-merge review only when speed of remediation is more important than process. In that case the change is reviewed retroactively within one business day, the deviation is logged in the incident record, and any quality gates that were skipped are re-run before the change is considered closed.

4. Rollback

• Every deployment is reversible. Tagged commits make code rollback a single operation.
• Schema changes are designed forward-compatibly: the previous code version continues to work against the new schema until the deploy is committed. Rollback of the schema itself is rare and requires explicit approval; data preservation rollback procedures are documented inline with each migration.
• Configuration rollback is a config-store revert.
• Rollback decisions are made by the deploying engineer with input from the policy owner if the deploy was a SEV-level change.

5. Audit

• Source-code history is preserved on every change with the actor, timestamp, and review trail.
• Production deployments are recorded with the deployed commit, the deployer, and the deployment time.
• Configuration changes are recorded via the same version-control trail as code.
• This audit trail is one of the inputs to the SOC 2 readiness program.

6. Roles and responsibilities

• Policy owner — Bella platform engineering lead.
• Reviewer — a second engineer with relevant context for the change.
• Annual review — this policy is reviewed at least once per calendar year and on any material change to the deployment toolchain.