Block on checks that are accurate, cheap to fix and tied to real harm. Warn on checks that are useful but noisy. Inform on checks you are still learning from. Promote a check from one level to the next based on measured false positives, not on opinion.
Three levels, defined
- Block: the pull request cannot merge until the check passes or an approved exception exists.
- Warn: the check posts a visible comment and the pull request can merge.
- Inform: the result is recorded and shown on a dashboard, with no pull request comment.
A golden path that blocks everything gets bypassed. One that blocks nothing is a suggestion. The levels let you be strict where it counts.
Starting table
| Check | Starting level | Reason |
|---|---|---|
| Lockfile missing or out of sync | Block | Deterministic, easy to fix |
| New dependency with a known critical vulnerability that has a fix | Block | Clear harm, clear fix |
| New dependency with a known high vulnerability and no fix | Warn | Needs a decision, not a wall |
| Package from outside the approved registry | Block | Policy breach, not a judgment call |
| License outside policy | Warn, then block | Needs legal input on the policy first |
| Package very new or low reputation | Warn | Signal, not proof |
| Old finding in an existing dependency | Inform | Handled by the cleanup schedule |
| Reachability unknown | Inform | Treat as data, not a verdict |
Adjust to your risk. The order matters more than the exact cells.
Rules for promotion
- A check starts at Inform or Warn for a trial period.
- Track how often developers dispute it or mark it wrong.
- If disputes stay low and fixes are cheap, promote to Block with advance notice.
- If disputes are high, fix the check or the data before promoting.
- Write the reason down, so the decision survives a staffing change.
Exceptions need an expiry
Every block needs a way out for real cases. An exception should name an owner, a reason and an end date, and the end date should trigger a review. See security exceptions without a ticket queue for a lightweight model.
Say what happened in plain language
A failure message should state what failed, why it matters, and the next step in one or two lines. Include a link to the fix guidance. Developers forgive blocks that explain themselves.
Review the levels quarterly
Checks drift. A scanner update can change noise levels, and a new advisory feed can add volume. Put a short review on the calendar and compare each check's dispute rate to its level. Move checks down as readily as up.
How gates relate to the template
The template carries the default levels, so every new service starts with the same rules. Teams may tighten but should not loosen without an exception. See what belongs in a golden pipeline for the surrounding pieces.
Where Safeguard fits
Safeguard provides policies, gates and guardrails you can set per check, reachability analysis to help decide which findings deserve a block, and fix PRs (off by default, every category on Manual). Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo, trigger the gate, and notice what the developer sees when a check blocks.
Click through it at your own pace, or open it full screen.
Quick check
Should every critical finding block?
Block when a fix exists and the check is accurate. Without a fix, a warning plus a documented decision is usually more workable.
How long should a trial period last?
Long enough to see real dispute data, often a few weeks across several teams. Set the length in advance.
Last reviewed: 19 October 2026.
