Write a rule in a document when it needs judgment or context, and enforce it with a check when it is objective, frequent and cheap to test. Most mature teams do both: the document explains why, the gate makes the right path the easy one.
The difference in one table
| Written rule | Enforced check | |
|---|---|---|
| Works through | Reading and remembering | Automation at the point of change |
| Suited to | Judgment calls, context, exceptions | Objective yes or no conditions |
| Failure mode | Not read, read late, interpreted differently | Too strict, noisy, or bypassed |
| Cost to change | Edit a page | Edit a rule and test it |
| Evidence | A signed acknowledgment | A log of passes and blocks |
Rules that suit a gate
A check suits a rule when the answer is mechanical:
- A dependency with a known critical vulnerability, where the vulnerable function is reachable, must not merge.
- A new package must come from an approved source.
- A build must produce a software bill of materials.
- A container image must come from an approved base.
These repeat on every pull request. Humans are poor at repeating them consistently, and good at everything else.
Rules that need a document
Some rules cannot be reduced to a test:
- Whether to accept a risk, and for how long.
- How to design an authorization model.
- When to disclose a vulnerability.
- How to treat a borderline third party component.
Write these as guidelines and decision records, and give people a path for asking questions. See which security document to write.
A rollout that avoids backlash
- Write the rule and the reason first. People accept a gate faster when they understand it.
- Run the check in report mode. Let the team see what would have blocked, with no consequence.
- Tune it. Fix false positives and unclear messages. A gate that blocks on noise teaches people to resent it.
- Warn, then block. Move a rule from warning to blocking once the noise is low.
- Provide an exception path. A quick, recorded waiver is safer than a quiet workaround.
- Link the failure message to the page. The block message should say what failed, why, and what to do.
The same sequence applies to all gate types. Deploy gate block, warn or approval goes deeper on choosing the level.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how the failure message points to the specific finding, which is what turns a block into a fix.
Where Safeguard fits
Safeguard policies, gates and guardrails apply dependency and vulnerability rules at the pull request, and autonomous remediation can open fix pull requests. Remediation is off by default, with every category on Manual until you change it.
Quick check
Do I still need a document if a gate enforces the rule?
Yes. The gate shows what is blocked, the document explains why and how to request an exception.
Should every rule be a blocking gate?
No. Start in report mode, and block rules with low noise and a clear owner.
Last reviewed: 19 October 2026.
