Freezing a Release at Sign-Off
Sign off a release and its analytics stop moving. Hawzu snapshots the defect picture — and the acceptance criteria it was judged against — so a release that shipped as Ready still reads Ready a year later.
Someone opens a release that shipped in March. They’re answering a question from an auditor, or arguing about a regression, or just curious. The release page loads and the numbers are different from the ones in the sign-off email.
Nothing was tampered with. Two defects raised against that release were closed in April. One was reopened in June. Another got relinked to a different release when someone tidied the board. Every one of those was a correct, ordinary action — and every one of them changed a report about a decision made in March.
A report that recalculates is not a record
This is the quiet failure mode of every derived metric. The number is honest, the inputs are honest, and the answer still drifts, because the report is a function of now being asked a question about then.
For most screens that’s exactly right. Your open-defect count should reflect today. But a sign-off isn’t a screen. It’s the moment someone accepted risk on behalf of a team, and the only useful version of it is the one they were looking at.
A live report answers “how are we doing?”. A sign-off has to answer “what did we agree to?” — and those need different storage.
So completing a release freezes its analysis. The derived picture is computed one final time and written to a snapshot, and every read after that point serves the snapshot instead of recomputing.
Freeze the analysis, not the release
The distinction matters, and it took us a while to get right.
The obvious implementation is to freeze the release — lock everything, refuse all writes, done. That’s wrong for the same reason locking an entire finished run is wrong. After sign-off, work continues: defects get triaged, closed, reopened, relinked. A release that refuses all of that stops being useful the moment it’s signed.
So what’s frozen is narrower than it first appears.
Test results don’t need snapshotting at all — they’re already immutable, held by the editability guards that lock a completed run. Recomputing them a year later gives the same answer, because nothing can have changed them.
Defect data is the opposite. Linking, unlinking and status changes all stay live by design, which is precisely why the defect picture is the thing that needs capturing. So the snapshot holds only the defect-derived analytics. Not everything — the one part that would otherwise drift.
That’s the general shape: snapshot what can move, and leave what can’t alone. Freezing something already immutable is duplication with a maintenance cost.
One instant, shared all the way down
A release has child runs, and each of those has its own defect picture and its own sign-off report. Which raises an easy problem to get subtly wrong: what instant does each one freeze at?
Freezing each at its own “now” is the obvious implementation and it produces an aggregate that doesn’t reconcile with its parts — the release says eleven open defects, and the four runs beneath it add up to twelve, because one closed in the eight seconds between two writes. Nobody can explain that later.
So when a release freezes, its child runs freeze with it, at the release’s instant, not at their own. Every drill-down and the aggregate above it report the same moment. A run that completed on its own earlier keeps its own timestamp, because that sign-off happened when it happened — but a run frozen as part of a release inherits the release’s.
Freeze the bars, not just the numbers
Here’s the part that isn’t obvious until it bites.
A readiness verdict isn’t just numbers — it’s numbers compared against thresholds. Coverage target, acceptable failure rate, how many open criticals are tolerable. Those live as a parameter passed into the calculation, which is what makes them adjustable.
Which means freezing the numbers alone doesn’t finish the job. Raise your coverage target from 80% to 90% next quarter and every historical release gets re-judged against a bar that didn’t exist when it shipped. A release that went out as Ready starts reading Not ready — with the signed certificate in the file drawer still saying otherwise.
So the snapshot captures the criteria too. A release is permanently judged against the bar it was actually held to. Tightening your standards changes what you demand next quarter; it doesn’t retroactively convict last quarter.
Reopening throws the snapshot away
The last rule keeps the whole thing honest: reopening a release deletes its snapshot.
That sounds like losing data, and it’s the only correct behaviour. A snapshot claims to be the state at sign-off. If the sign-off has been withdrawn and the release is live again, that claim is false — and a false record is worse than no record, because it’s the one people trust.
The same rule runs one level down: resuming a completed run deletes the defect snapshot it took on completion. Reopen, and you’re live again, all the way down.
None of this is complicated. It’s four rules — snapshot only what can move, share one instant, capture the criteria, drop it all on reopen — and together they’re the difference between a sign-off you can produce a year later and a page that merely renders the same layout.
A sign-off has to keep saying what it said. That means storing it, not recomputing it.
The release sign-off report
