A Release Can Be Complete and Not Ready
A release status records what a person decided. Readiness records what the evidence says. Hawzu keeps the two separate — and puts hard gates in front of the score, so a good average can't hide an open blocker.
A release can be marked Complete with three critical defects open against it.
Nothing in Hawzu stops that, and nothing should. Someone decided to ship. Maybe the defects are in a feature that got flagged off, maybe there’s a hotfix scheduled, maybe it was a bad call. A status field records what a person decided. It was never in a position to check.
The problem starts when one status field is quietly doing both jobs — recording a decision and implying a verdict — and readers can’t tell which one they’re looking at.
Two things wearing the same word
There are two genuinely different questions here.
Where is this release in its lifecycle? Not started, in progress, paused, completed, archived. This is scheduling, and scheduling is a human matter. A release paused because a customer moved a date isn’t a data condition; no amount of test evidence implies it. So in Hawzu this is set by a person, with only two rules: you can’t send a release back to not-started, and nothing leaves archived.
Is the evidence good enough to ship? That one has an answer in the data, and it should never be typeable. If a person can type it, then sooner or later it says Ready because someone was optimistic on a Friday, and it means nothing afterwards.
A status records a decision. It can’t check one.
- Not started
- In progress
- Paused
- Completed
- Archived
Nothing feeds this. It records a decision.
No one can type this. It reports a finding.
Splitting them costs you the comfortable ambiguity of a single field and buys you a release page where the two disagree out loud. Completed, and Not ready. That’s not a contradiction to be designed away — it’s the most informative thing the screen can tell you.
Gates first, score second
Readiness combines four parts into a weighted score: Test Execution, Quality, Defect Health and Requirements. When a release traces no requirements, that part is left out rather than scored as zero, so a release isn’t marked down for something that doesn’t apply to it.
But a weighted score on its own hides blockers. A release with a 96% pass rate, most of its tests run and one open critical defect computes to a high number, and that number is a lie by arithmetic. Averages are built to let strong parts absorb weak ones. That’s the whole point of them, and it’s exactly wrong for a ship decision.
So gates come first. Each one is a bar: enough of the release executed, a fail rate under control, no open critical defects, a defect logged for every failure, enough requirements verified. The hard ones — an open critical, a fail rate over the line, too many failures with no defect — veto the score outright and name the cause. Only if nothing is gated does the score get to speak. The verdict is one of four: Ready, At risk, Not ready or Not started.
The number had to leave the browser
Readiness used to be calculated in the browser. Three different screens each turned the same raw numbers into a verdict, each in its own way.
Two of them disagreed.
Neither was wrong, exactly — they’d drifted through ordinary maintenance, the way three copies of anything drift. The bug wasn’t in either version. It was in there being three. So the whole calculation moved to one place on the server, as plain arithmetic that touches nothing else: hand it counts, it hands back a verdict.
Moving it surfaced a second trap. The old and new versions of the calculation rounded exact halves differently: one turned 2.5 into 3, the other into 2. Same inputs, same formula, different score — and only on exact halves, which is rarely enough to ship and often enough to be found by a customer rather than by us. The server now rounds the way the browser always did, and the two agree.
The related discipline: every percentage is worked out from the raw counts, never from another percentage that’s already been rounded. Round once, at the end, or you spend the rest of the calculation compounding a number you threw precision away on.
What the calculation refuses to decide
Two things are deliberately left out of it.
It doesn’t pick colours. A verdict comes back with a meaning — critical, caution, good, neutral — and the screen decides what that looks like. A calculation that names colours has opinions about a screen it can’t see, and the first time you show it somewhere else, the opinions come with it.
And it doesn’t own the bars. The thresholds are handed to the calculation, not built into it. Two of them look interchangeable and aren’t: the share of your suite that’s been executed and the share of your requirements that have been verified are different claims that happened to be set to the same number. Keeping them as one setting would have been a bug waiting for the first team that cared about one and not the other.
To be straight about where this stands: each release could carry its own acceptance criteria, but nothing in the product sets them yet. Every release today is scored against the same defaults.
What is shipped is that sign-off freezes the bars along with the numbers. When a release is signed off, the criteria it was judged against are frozen into the snapshot with it. Without that, any later change to the bars would retroactively re-judge every release you ever signed off — and a release that shipped as Ready would quietly start reading Not ready, with the sign-off certificate still saying otherwise.
Both fields, on purpose
The release page shows what a person decided and what the evidence found, side by side, and never lets one overwrite the other. The lifecycle is yours. The verdict isn’t for sale.
That’s the same commitment a frozen test run makes, one level up: the record of what happened doesn’t bend to what anyone would prefer it said.
If a person can type “Ready”, it stops meaning anything the day someone does.
The release readiness report
