The change record nobody can write
Every regulated release ends at a form. The form asks what changed, what it might affect, and how to undo it. It is filled in at the end of the week by whoever is available, working from memory, against a deadline. The answers are then used to assess risk.
Nothing here is dishonest. It is what a person can produce in four minutes without the merge history, the dependency graph and the migration list open in front of them. The approval board then assesses risk using it, which is the part that should worry you.
The risk assessment is written by the person with the least context, at the end of the week, from memory.
refund_approvals table. 7 pull requests,
4 contributors, 23 files.billing-reconciliation, support-console,
partner-apiV214__refund_approvals.sql drops orders.refund_note.
Roll back requires the restore procedure below.None of this is inferred or estimated. Every field is derived from something already recorded, which is also what makes it auditable — each answer can be traced back to the artifact it came from.
| Field | Assembled from | Why a person cannot do it at 16:52 |
|---|---|---|
| Description | Merge commits between the deployed tag and the release candidate | Requires reading 7 pull requests written by 4 people over 3 weeks |
| Affected systems | Consumers registered against the changed API contract | The consumers are in other repositories, owned by other teams |
| Risk | Presence of a non-reversible migration; contract change with external consumers | Risk is currently a dropdown chosen by feel, with no inputs |
| Rollback | Migration files in the diff, checked for reversibility | “Redeploy the previous version” is the default answer and it is wrong here |
| Testing | Build 4.18.0 result and its criteria coverage gate | “Tested in UAT” is true and says nothing |
Redeploying the previous version does not restore
orders.refund_note.
Migration V214__refund_approvals.sql drops the column as part of moving
refund notes into the new table. Redeploying the old build restores code that reads a
column which no longer exists, so the rollback fails in exactly the situation where it
is needed — and fails after the deployment has already been reverted,
when the pressure is highest.
Nobody wrote a wrong answer deliberately. “Redeploy previous version” is correct for the great majority of releases, which is precisely why it is typed without checking.
| As filed | Actual | Consequence |
|---|---|---|
| Affected: order-service | 4 services — 3 consume the changed contract | Three teams unaware their integration changed |
| Risk: Low | Medium — irreversible migration, external contract change | Approved under the wrong review path |
| Rollback: redeploy | Requires column restore before redeploy | Rollback fails during a live incident |
| Testing: tested in UAT | 3 acceptance criteria unverified | Approval granted on an incomplete picture |
The change record still goes to a human to approve. It arrives with the work already done, sourced from artifacts rather than recollection, and with the one field that would have failed during an incident marked as blocking.