Skip to content

Release-evidence guide

Risk-based quality gates in CI/CD

A quality gate is a decision point in the delivery flow. Risk-based design connects the gate to the change, the evidence available at that stage, and the action expected when evidence is incomplete.

Published:
Updated:

Direct answer

A risk-based quality gate is a contextual release rule, not a universal score.

It states which decision the gate controls, which changes it applies to, which evidence is required at that point, what happens when evidence is missing or unstable, and who can authorise an exception.

Decision criteria

A useful gate makes five decisions explicit.

Controlled decision
The gate states whether it can continue, pause, or escalate a delivery decision.
Change context
The rule responds to affected components, dependencies, change type, and relevant risk rather than every change equally.
Signal validity
Required checks have defined versions, environments, data, timing, and freshness conditions.
Exception path
Missing or unstable evidence triggers a named review path instead of a silent bypass.
Accountability
Rule maintenance, result review, exception authority, and the final release decision have owners.

Evidence to examine

Define the decision before the rule.

State what the gate may allow, stop, or escalate; which changes it applies to; and who can interpret or override it. This keeps the rule tied to release context rather than one universal score.

  1. 01

    Change context

    The affected components, dependencies, change type, and risks relevant to the decision.

  2. 02

    Evidence threshold

    The checks and signals required at that point, with the conditions under which they remain valid.

  3. 03

    Exception path

    How missing, unstable, or unavailable signals are handled and how the rationale is recorded.

  4. 04

    Ownership

    Who maintains the rule, reviews the result, and holds release authority.

Practical checklist

Review a gate with this checklist:

  1. 01Name the release decision the gate controls.
  2. 02Define which change contexts activate the rule.
  3. 03List required signals and their validity conditions.
  4. 04Specify how missing, stale, or unstable results are handled.
  5. 05Assign maintenance, review, and exception authority.
  6. 06Record the result, rationale, uncertainty, and next action.

Common failure modes

Quality gates fail when the rule loses its context.

One threshold for every change

A universal score ignores different components, dependencies, failure consequences, and available evidence.

A bypass without a decision record

The pipeline continues, but the missing evidence, owner, rationale, and follow-up disappear.

A technically green but stale gate

The required check passes even though its data, environment, version, or test selection no longer matches the release.

Illustrative example

Fictional scenario · not client work

A fictional change-sensitive gate

A fictional release changes a critical workflow and a shared dependency. The gate applies because both areas are within the recorded change boundary.

Decision question: can delivery continue with the current evidence, or does the dependency change require escalation?

Required signals: targeted automated checks, dependency health, environment validity, known-defect review, and an accountable approval record.

One targeted check is unstable. The result is not silently counted as passed; it is marked as unresolved evidence.

The named owner either obtains a valid rerun or records an exception, its rationale, compensating evidence, and follow-up action.

This fictional gate illustrates a decision pattern only. It is not a client pipeline, a universal threshold, or proof of an outcome.

How the signals connect

Treat the gate as part of an evidence flow.

Automated checks, environment state, known defects, approvals, and residual uncertainty need a clear path into the gate. The gate should expose the basis of a decision, not hide it behind pass or fail.

Evidence boundary

A gate is not a guarantee.

Passing a gate shows only that its defined conditions were met with the available evidence. It does not establish the absence of defects or remove the need for judgement and exception ownership.

Related paths

Review the gate in its delivery context.

Use the assessment when the decision, evidence threshold, and ownership still need to be defined together.

Start with the assessment