Write down the assumption that failed
A release note is more useful when it records the mistaken belief that shaped the incident, not only the fix that followed it.
Release notes often get cleaned up too early. The final record says what changed, who approved it, and which issue was fixed. That is useful. It still leaves out one of the most valuable operational facts: what the team believed before reality disagreed.
We want the note to keep that failed assumption in plain language. If the team believed a patch only touched copy but it actually altered a permission path, write that down. If the team assumed the installed native binary matched the OTA target and it did not, keep that sentence. If the team thought store processing had completed when it was only queued, keep that too. The mistaken belief tells the next reviewer where judgement drifted, not only where code changed.
The fix is only half of the lesson
A plain fix note can sound complete: reverted configuration, rebuilt artifact, resubmitted to TestFlight, corrected signing profile. The team may indeed have fixed the immediate problem. But if the release record omits the assumption that made the problem believable in the first place, the same shape of mistake can return under slightly different conditions.
That is one reason operational memory should hold more than the final action. We want the record to show which mental shortcut failed. The build looked production-safe because only one file appeared to change. The rollback looked straightforward because everyone assumed the previous artifact was still the last accepted one. The approval felt calm because the release owner believed a warning was informational rather than gating. Those are the details that improve the next decision.
Wrong assumptions create release debt fast
Release work moves across people and hours quickly. A shaky assumption that stays unwritten becomes folklore instead of evidence. The next engineer sees the fix commit but not the reasoning error. Support sees the outcome but not the mistaken belief that delayed the right response. A later approver may repeat the same shortcut because the system preserved the artifact trail and the status changes, but not the judgement that broke.
We would rather preserve that judgement plainly. Assumed OTA target matched the installed binary. Assumed store upload completed after processing started. Assumed the rollback candidate had already passed the latest smoke. These are small sentences, but they turn a release note into something a future operator can actually learn from.
This is not about writing blame into the record. Mature release notes should make the team sharper, not embarrassed. The wrong assumption matters because it narrows where the next review should look, which checklist needs improving, or which surface needs stronger proof before approval.
A good release record explains why the team changed course
When a release shifts direction, the evidence should answer more than what happened next. Why did we stop. Why did we revert. Why did we resubmit. Why did we hold the rollout at internal instead of sending it further. The assumption that failed is often the cleanest answer to that question.
If the note only says reverted after smoke failed, it misses the more useful lesson that the team treated the earlier smoke as stronger evidence than it really was. If it only says resubmitted with corrected metadata, it hides that the team had assumed the existing store state was still aligned with the current artifact. Recovery becomes easier to trust when the release note captures the mistaken premise beside the fix.
The next reviewer should inherit the judgement break
We build Ubriot around release memory because release reliability depends on better questions as much as better pipelines. Once the wrong assumption is visible, the next reviewer can ask the right follow-up sooner. What proof would have disproved this earlier. Which release surface hid the difference. Was the problem in the artifact, the channel choice, the store state, or the team handoff.
That kind of note does not need to be long. It needs to be honest enough that the next release does not inherit the same blind spot. A release note that preserves the failed assumption gives the team more than a history of changes. It gives the team a record of judgement, which is often the real thing that needs to improve.
That is the record we want by default. Preserve the artifact. Preserve the store answer. Preserve the rollback path. Preserve the assumption that turned out to be false. The fix tells you what changed. The broken assumption tells you why the release drifted. Keeping both in the same note makes the next approval calmer and the next rerun more honest.