ReleaseGate

In release meetings, "can we ship this?" is decided by gut feel and whoever speaks loudest. The defect list QA gathered sits in the tracker; the user-impact reads PM has live in Slack threads; the change-risk areas engineers know are scattered across PR comments. There's no place where the same information can be compared on the same screen at the same score, so the call falls onto whoever sounds most certain - and that person's mood and air-time creep into the decision. The real problem is that no two people in the room ever read the same one-line answer for "release confidence."

Fourteen years in QA showed me the same pattern in release meetings, repeatedly: long checklists, no single answer for "release confidence," so the call falls to whoever sounds most certain. The hypothesis behind starting this: the gap isn't that the tools are missing - it's that the decision itself has no tool. The same question keeps recurring in companies that already have JIRA, test reports, and code review.

PO/PM holding the release call, QA leads watching the risk, engineering managers locking the date.

Express release readiness as a single 0-100 confidence score plus a GO / HOLD recommendation, and the conversation shifts from debate to verification.

• Designed the Release Confidence Score (0-100) - weighted blend of coverage, open defects, and change-risk areas
• Report UI that shows the GO / HOLD recommendation alongside its reasoning
• AI-drafted test case starters so QA opens an editable draft rather than a blank screen
• PDF report export for stakeholder sharing

• Single headline number on the score - so a meeting can begin with "what's the number?" instead of debate
• GO/HOLD shown as a recommendation only, never a verdict - acknowledging the limits of automation
• PDF export over integrations for the MVP - minimizing adoption friction

• Score reproducibility - the same inputs (coverage, open defects, change-risk) yield the same confidence score (deterministic rubric)
• The GO/HOLD recommendation and the human final call stay clearly separated - so it isn't mistaken for an automated verdict
• Input boundaries - empty input and the 50,000-char overflow are safely rejected (TC-P0-001/002)
• Output structure splits consistently by blocker-present/absent (TC-P0-012~015 pinned as regression)
• The LLM response is pinned with a deterministic mock so score computation stays a regression target
• The risk register (docs/03) attaches a verification method and a Mitigated/Open status to most risks, so risk-based verification is traceable from the docs
• The places it falls short of its own gate are surfaced honestly - committed automation concentrates on the CLI rubric, test_go_nogo.py is an empty placeholder, and the web-app E2E and coverage targets (docs/05) are still only aspirational

MVP stage. Early user interviews in progress; quantitative metrics not yet measured.

Confirmed how hard it is to fit "the weight of a release decision" onto one screen. Putting up a one-line score is easy, but for that score to land in a meeting, "how did this score come to be?" has to be visible on the same screen right next to it. If the score is the start of a decision, the reasoning view is the safety net behind it. The next round tests the hypothesis that adoption depends on how the reasoning is presented, not on the number itself.

• Round one led with the single score as the headline, which pulled "do I trust the number?" forward too fast. Round two starts from the reasoning UI behind the score.
• Trading integrations for PDF export in the MVP - to minimize adoption friction - was the right move for first entry, but it left thin signal on how the report actually gets used in meetings.