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.

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.

Change context
The affected components, dependencies, change type, and risks relevant to the decision.
Evidence threshold
The checks and signals required at that point, with the conditions under which they remain valid.
Exception path
How missing, unstable, or unavailable signals are handled and how the rationale is recorded.
Ownership
Who maintains the rule, reviews the result, and holds release authority.

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.

Practical checklist

Review a gate with this checklist:

  1. Name the release decision the gate controls.

  2. Define which change contexts activate the rule.

  3. List required signals and their validity conditions.

  4. Specify how missing, stale, or unstable results are handled.

  5. Assign maintenance, review, and exception authority.

  6. Record the result, rationale, uncertainty, and next action.

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.

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

A fictional change-sensitive gate

Fictional scenario · not client work

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.

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.