# Production change notification

There is a gap between "we deploy continuously and trust the pipeline" and "every change goes to a review board that meets on Tuesdays". Most organisations running revenue-critical systems need something in that gap: a short, written declaration before a change touches production, reviewed by people who can say no.

This is that. It works because it is small. The moment it becomes long, engineers start batching changes to avoid the paperwork, and batching is the thing that made deployments dangerous in the first place.

## What requires a notification

Be explicit, because ambiguity here produces either bypassing or over-reporting.

```
Requires notification:
  — schema changes or data migrations
  — infrastructure, DNS, certificate or network changes
  — changes to authentication, authorisation or payment paths
  — third-party integration changes, including credential rotation
  — anything that cannot be rolled back by redeploying the previous version
  — first release of a new service or a new environment

Does not require notification:
  — routine application releases that pass the standard pipeline
  — content and configuration changes through an intended interface
  — hotfixes under an active C1 incident (declared retrospectively,
    within one working day)
```

That last exception matters. A process that stands between a team and the fix during an outage will be ignored, and rightly — so make the exception explicit rather than pretending it will not happen.

## The template

```
# Production change: [short description]

Requested by:
Target window:        date, time, expected duration
Systems affected:
Change category:      schema / infrastructure / integration / auth / other

## What is changing
Plain description. A reviewer who does not know this codebase should
understand the scope.

## Why now
Including what happens if this waits.

## Risk
What could go wrong, and how likely. If the honest answer is
"we are not sure", say that — it is a valid reason to add a reviewer,
not a reason to write something reassuring.

## Blast radius
If this goes wrong, what stops working, and for whom.

## Rollback plan
The exact steps, and how long they take.
"Redeploy the previous version" is only a rollback plan if the change is
reversible that way — schema and data changes usually are not.

## Verification
What we will check immediately after, and what tells us to roll back.
Include the metric or log signal, not just "check the site works".

## Dependencies and notifications
Other teams, partners or stakeholders who need to know before or after.

## Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| Technical reviewer | | approve / approve with conditions / reject | |
| Delivery owner | | | |
| Business owner (if user-facing) | | | |
```

## The design decisions worth copying

**Three named approver roles, not a committee.** Technical soundness, delivery timing, and business impact are different questions with different right answers, and one person rarely holds all three. Keep it to roles rather than a standing meeting.

**"Approve with conditions" is a first-class outcome.** Most reviews are not binary. Allowing a conditional approval — ship it, but in a low-traffic window, with a specific check first — means reviewers stop rejecting things just to force a conversation.

**Blast radius is separate from risk.** Risk is about likelihood; blast radius is about consequence. A low-risk change with a wide blast radius deserves a different window than a high-risk change affecting one internal tool, and collapsing them into a single "risk" field loses exactly that distinction.

**Verification names a signal.** "Check that it works" produces a page refresh. Naming the metric or log line that would indicate failure means the person doing the check knows what they are looking at, even if it is not the person who wrote the change.

## Keeping it alive

Two failure modes, both common.

It becomes a formality — notifications get written after the decision, approvals are rubber-stamped. The counter is to look at rejections and conditions: if the process has never changed an outcome, it is not a process, and you should either fix the reviewer set or drop it.

It becomes an obstacle — the form grows, the window shifts, engineers batch changes to reduce the number of notifications. The counter is to periodically cut fields. If a field has not influenced a decision in three months, remove it.