A fail is rare and specific. It means a critical finding: on the checklist, critical is reserved for data exposure, money, or account takeover. Nothing else holds a release.
What happens in the first hour
The named QA lead reports the finding to your named contact within 4 business hours of confirming it; in practice it is minutes, because a critical finding is confirmed by re-running the item. The report has the checklist id, the pattern, a reproduction, and the build hash.
Most critical findings are one of a short list: a table without row-level security (database rules that decide which rows each signed-in user may read or write) (AC-01), a policy that allows everything (AC-02), an action that does not check the session (AU-02), a webhook (a message a provider such as Stripe sends to your server when something happens, like a payment) accepted without a signature (PY-01), an entitlement enforced only in the UI (PY-03), or a key in the bundle (the JavaScript your app sends to the browser or ships inside the mobile app; anyone can read it) (SC-01). Each of these has a fix that is usually small.
The same-day re-test
Because the fix is small, the re-test usually happens the same day. The record then shows two builds: the one that failed and the one that passed, with the same checklist version. The synthetic sample report shows this shape in releases R-035 and R-036: a new invoices table shipped without a policy, the release was held, the policy was added, and the re-run passed.
What a hold is not
A hold is not a judgement on the team or the tool that wrote the code. Missing policies on new tables are the single most documented failure on Supabase-backed apps, with a CVE filed for it on generated sites. (Source: NIST National Vulnerability Database, 2025-05-30 · verified 2026-09-21) The checklist exists because the pattern is common, whoever wrote the code.
A hold is also not a way to slow a team down. The item that held the release is added to the pre-merge CI (the pipeline that builds and tests every change before it can be merged or deployed) step where possible, so the next occurrence fails a pull request instead of a release. The sample report's next-month plan shows that step for AC-01.
When the fix is not small
Occasionally a critical finding is structural: entitlements enforced in the client across dozens of endpoints, or a shared database between development and production. Then the hold becomes a plan: what ships now with the risk stated, what the fix sequence is, and which releases re-test it. The verdict (a one-word release result (pass, pass with findings, fail) with the findings and the checklist version behind it) stays fail until the item passes, and the record says why the release shipped anyway, if it did. That decision is yours; the record makes it visible.