Release notes should keep the wrong assumption
A release record becomes more useful when it preserves the assumption that failed, 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 think release notes should keep the wrong assumption. If the team believed a patch only touched copy but it actually altered a permission path, that matters. If the team assumed the installed native binary matched the OTA target and it did not, that matters. If the team thought store processing had completed when it was only queued, that matters too. The failed assumption tells the next person 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 record should help the next reviewer ask better questions
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 keeps the wrong 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.
We want release notes to hold that value by default. Preserve the artifact. Preserve the store answer. Preserve the rollback path. Preserve the wrong assumption too. The fix tells you what changed. The assumption tells you why the release drifted. Keeping both in the same record is part of what makes the next approval safer.