A quality gate is a check that work must satisfy before it can move forward. Gates enable 'good enough to ship' to shift from a subjective judgement to something the system enforces consistently every time.
Blocking and advisory
Each gate falls into one of these categories, and this distinction lies at the heart of the design:
- Blocking — failure prevents the task from progressing until it meets the requirements or a human authorises an exception.
- Advisory — failure is logged as a finding and attached to the pull request, but the task continues regardless.
Start with advisory gates. Observe what a gate flags in actual work over a week or two, then upgrade those that prove effective to blocking status. A gate that blocks on day one, without proper tuning, typically encourages teams to find ways around it.
What gates can assess
Gates operate during the verification stage and can cover:
- successful completion of your own test suite
- coverage thresholds
- linting and static analysis
- security scanning
- browser tests run against a live preview
- evidence from external providers linked to the pull request
The most valuable gate is usually your existing test suite, as it already reflects the standards your team considers important.
Where a gate can halt work
Gates run during verification, after the developer agent finishes and before Review. A blocking failure sends the task back for rework instead of creating a pull request that would ultimately be rejected.
This sequence is intentional: it is cheaper to fail during processing than to fail once the work reaches your screen.
Policies
Gates are grouped into policies, which are the items you assign to projects. A policy is a named collection of gates along with their blocking/advisory settings, allowing you to apply one standard to production services and a less strict one to internal tools.
Policies are versioned. When you make a change, you can revert to a prior version if a new gate proves too restrictive.
Overrides
A blocking gate can be overridden by a person with the necessary authority. The override is recorded — including who did it, when, and for which task.
This record is essential. A gate that cannot be overridden at all will be circumvented by users; a gate that can be overridden without trace serves no real purpose. An override that leaves a trail is both practical and accountable.
What gates do not do
Gates assess specific properties. They do not determine whether the work addresses the right problem — that is the role of acceptance criteria in the specification and what your Review process is for.
A change can pass all gates yet still be the incorrect solution.