Release Readiness Gate

A release readiness gate is the last structured check a release manager runs before authorizing a go-live. It answers a narrow question: do open bugs, test coverage, and documentation meet the criteria this product has already agreed on for this train? If they do not, the gate should make the gap visible and keep the default action as “do not promote,” while still leaving the ship decision with the human who owns the release.

The gate is not a substitute for judgment about customer impact, timing, or business risk. It is a consistent evaluator of the evidence that usually drives those judgments. Practitioners who already use a service catalog or scorecard platform (for example Cortex) often hang the same checks there so ownership, ownership SLAs, and release policy live in one place. The LLM layer helps interpret messy ticket text, incomplete runbooks, and coverage reports; a rule engine enforces the hard thresholds that must not be negotiated away in the heat of a ship window.

Related workflows that sit next to this gate include an Automated Changelog Generator for release notes from commits, a Feature Flag Configuration Advisor for safe rollout defaults, and Post-Deploy Anomaly Detection for what happens after traffic starts.

The gate only runs when three input classes are present and attributable to the build under review:

1. Bug inventory for the release train: issue tracker export or API payload with severity, status, linked fix version or release, and whether each item is marked as a release blocker.
2. Coverage evidence for the same commit or artifact: unit, integration, and any required end-to-end suites, including absolute coverage figures and the baseline or floor defined in policy.
3. Documentation completeness for go-live: runbook or playbook updates, known-issue notes, rollback steps, and any customer-facing change summary the policy requires.

If any of those inputs is missing, empty, unreadable, or not tied to the candidate artifact, the gate produces empty output. It does not invent a green score from partial data, and it does not “assume fixed” for tickets it cannot see. Empty output is the correct failure mode: the release manager treats the gate as not yet runnable and either restores the feed or delays promotion until the inputs exist.

Optional context improves explanation quality but must not replace the three required feeds: ownership from a catalog, prior release outcomes, and policy documents that define severity mappings and coverage floors. When those are present, the LLM can explain why a rule failed in language a war-room can act on. When they are absent, the rule engine still fails closed on the required inputs alone.

Hard criteria belong in deterministic rules. Examples of rule-shaped checks include: no open severity-1 bugs linked to the release; no more than N severity-2 bugs unless each has an approved waiver; line or branch coverage at or above the team floor for changed packages; required doc checklist items present and non-empty. Rules return pass, fail, or insufficient-data. Insufficient-data maps to empty overall output when the missing piece is one of the three required inputs.

The LLM’s job is interpretation around those rules, not override. Typical tasks:

• Classify whether an open ticket is truly in-scope for this release when labels are inconsistent.
• Summarize clusters of related bugs so the release manager sees themes instead of a raw backlog dump.
• Score documentation completeness against a checklist: presence of rollback, monitoring pointers, and customer impact language, calling out sections that are stubs or copy-paste placeholders.
• Draft a short readiness narrative: what passed, what failed, and what evidence was used.

Policy still wins. If coverage is below the floor, the gate status is fail even if the model’s prose sounds optimistic. If a severity-1 remains open without an approved exception recorded in the tracker, the gate status is fail. The model may recommend next steps (reopen coverage jobs, reassign blockers, complete the runbook section), but it must not re-label a failed rule as a soft warning unless policy explicitly defines that severity as waivable and a waiver record exists.

When teams already track production readiness in Cortex or a similar scorecard, map each rule to a scorecard check so the gate result is visible to service owners outside the release channel. Keep the LLM summary attached as evidence, not as a second competing score.

A blocked result means at least one required rule failed on complete inputs. The output should list each failed criterion, the evidence used (ticket IDs, coverage artifact ID, doc paths), and a concise remediation hint. The release manager (or designated approver) remains the person who ships. The gate’s job is to make shipping without closing those gaps an explicit choice, not an accidental omission.

An empty result means the gate could not evaluate. Common causes: bug export timed out; coverage report missing for the exact SHA; docs folder empty or wrong branch; permissions blocked the catalog lookup needed to resolve ownership. Treat empty like a red light on the process, not a green light on the product. Do not promote on empty. Restore inputs and re-run.

A pass result means every required rule passed on complete inputs. Pass is not a guarantee of incident-free production. It means the agreed go-live bar for bugs, coverage, and docs was met at evaluation time. Continue with the rest of the release checklist: change window, on-call coverage, feature-flag defaults, and post-deploy monitoring.

Keep the human decision outside the automated path. Recommended operating model:

1. Pipeline or release bot runs the gate on the candidate artifact and posts the structured result into the release channel.
2. Release manager reviews failures or confirms pass. For failures, they either drive remediations, record a time-boxed waiver in the tracker with owner and expiry, or slip the train.
3. Only after that review does someone promote, tag, or flip the production flag. Automation may open the PR or hold the deploy job; a person still clicks ship (or an equivalent dual-control step your org requires).

Waivers need the same discipline as the gate. A waiver should name the failed rule, the residual risk, the owner, and when it expires. The next gate run should still surface the underlying gap until evidence changes. Otherwise waivers become invisible permanent debt.

For borderline cases (many low-severity bugs, coverage just under floor on untouched packages), the LLM summary helps the release manager decide quickly, but the rule outcome stays visible. If your org wants softer behavior for certain packages, encode that in policy and rules, not in ad-hoc prompts.

After go-live, hand off to monitoring and Post-Deploy Anomaly Detection. Upstream, keep changelog and flag configuration workflows aligned so the same release train does not pass readiness while notes or flags are incomplete. Pairing this gate with an Automated Changelog Generator and a Feature Flag Configuration Advisor reduces last-minute surprises that the readiness check cannot see on its own.

Start with a small rule set you already enforce manually: blocker bugs, coverage floor, and a short doc checklist. Wire the three required feeds with clear empty-on-missing behavior before adding smarter classification. Publish the policy next to the scorecard so engineers know what “blocked” means before release week. Run the gate in advisory mode for a few trains if you need trust-building, then flip the deploy hold so a fail or empty result stops promotion by default while the release manager retains override with an audited reason.

Measure usefulness by cycle time to clear real blockers and by how often empty outputs expose broken telemetry, not by how often the model writes longer summaries. The durable value is a repeatable go-live bar: same inputs, same rules, explicit human ship decision, and no silent green when bug, coverage, or doc evidence never arrived.