The backup fix worked. The older format still needs an answer.

There is a pleasing moment in this hypothetical backup review: the cleanup has been merged, and backups finish on time in the configuration the team tested. Then someone asks about the older data format. Nobody has a result for it yet.

Both things can be true. The delivered work has helped, and part of the risk remains unsettled. A risk registry keeps those facts together without forcing them into one “done” box. It records how the failure happens, what the team intends to do about it, what the checks demonstrate and which question still needs an answer.

The backup is spending its window on an old list

In our example, stale records keep accumulating. Before the backup can protect current data, it has to work through that outdated inventory. Listing the records, the step called enumeration, eventually takes so long that the job misses its completion window.

Once you can picture the delay, the proposed fixes stop looking interchangeable. Cleanup shortens the list. Repairing how records are created and retired prevents the same accumulation from returning. An earlier warning gives someone more time to respond, but it does not make enumeration faster. Even cleanup has a condition: some records may still be needed by active operations. Deleting everything that looks old would exchange one problem for another.

The registry does not need a second copy of the entire incident account. Link the postmortem and the implementation work so someone can follow the reasoning back. Google's postmortem guidance describes learning from an incident and following through on preventive actions. The registry carries forward a related job: keeping an unresolved choice available when later planning decisions are made.

What the successful backup has actually told you

“Enumeration finishes within the backup window at this record count” is something a test can examine. “Backup reliability is fixed” quietly expands the claim to other configurations, regions, scales and restore paths. The test has not become less useful because that larger sentence asks more of it.

Suppose bounded cleanup, backup and restoration all work for one supported configuration. Record that result and close the part it demonstrates. The older format can then get its own next decision: test it, contain the exposure, retire it, or have an authorized owner accept the remaining risk under stated conditions. You need not reopen the successful cleanup just to keep that question visible.

Restoration deserves its own check. A backup that finishes on time helps keep the saved data recent. It does not show whether that data can be restored correctly or how long restoration takes. If someone will later depend on a recovery-time claim, they need a result from the recovery path, not just a reassuring backup completion time.

A completed change can leave two different outcomes

Follow the decision in words

The diagram starts with the failure, its affected scope and consequence. An owner chooses mitigation, investigation or acceptance with an expiry. Delivery implements the selected change, and verification examines the mechanism within the stated scope. The path then branches: close the portion demonstrated, while keeping an owned decision for the exposure that remains. The two branches allow progress and an unfinished question to stay visible together.

Who can decide to keep the older format?

The engineer who wrote cleanup may know exactly how it works without being authorized to accept the customer exposure of leaving an older format untested. Implementation knowledge and authority to carry that consequence are different responsibilities.

Sometimes another treatment costs too much or introduces a more serious competing risk. Acceptance can be a legitimate choice, rather than an admission that nobody finished the job. An authorized decision maker needs to record the scope, the reason, a review or expiry date, and anything that should reopen the question sooner. This is risk disposition: deciding what to do with the exposure that remains. Once acceptance expires, it comes back for review; silence does not renew it.

Priority labels help arrange that discussion, but they are not measured probabilities of loss. A destructive failure with sparse evidence may deserve attention before a frequent inconvenience. Keep the reason for the choice with the record, so new information or a change in capacity can lead to a better decision instead of another argument about the label.

Three finished tickets might address one risk

The backup problem could produce three tasks: add a warning, repair cleanup and test restoration. Conversely, one repair to the way records are created and retired might reduce several risks. Counting tickets and counting risks will therefore tell different stories, even when everybody records the work accurately.

The more useful report says what changed. Perhaps a recovery route was exercised, an alert reached a staffed owner, or a failure mechanism was contained for a defined group of systems. An acceptance may instead have expired and need a decision. These are possible results to report, not outcomes claimed for a real incident here. They remain meaningful even if the investigation uncovers more unfinished work.

For our example, the report can say that cleanup shipped and backup-and-restore checks passed for the named configuration, while the older format has a decision owner and a next review. Now a planner can fund that missing test without being told the delivered cleanup somehow stopped counting.

This separation does not require a permanent second record for every edit. Durable risk tracking earns its effort when exposure is material, verification is incomplete, or a choice crosses ownership and planning boundaries. A small local correction can stay beside its delivery evidence when nothing important would disappear that way. The registry should preserve decisions people would otherwise lose, not give every ticket a twin.

Leave the next reviewer enough to make the decision

A reviewer returning to the backup question should not have to reconstruct why cleanup was chosen or guess which configuration passed. A compact record can keep that reasoning and its limits in one place.

The postmortem follow-through guide follows one corrective action. The registry holds the choices that can outlast several of those actions.

Back at the review, the team no longer has to choose between celebrating the cleanup and admitting the older-format gap. The tested improvement can stand. The unanswered question has someone to take it forward. That is a more useful finish than asking one closed ticket to say both things.