Score each AI suggested fix from 0 to 2 on seven criteria: root cause, scope, tests, data accuracy, side effects, evidence and rollback. A high total with no zeros can go to normal review. Any zero on root cause, tests or data accuracy sends it back for rework.
Why a scorecard
Reviews drift. One person is strict on Monday and tired on Friday. A short rubric makes reviewers look at the same things each time, and it produces a record you can total across a quarter. It is a team tool, not a formula that replaces judgment.
The seven criteria
Score 0 for not met, 1 for partly met, 2 for met.
| Criterion | 2 means | 0 means |
|---|---|---|
| Root cause | The change addresses the weakness class | Only the flagged line or symptom changed |
| Scope | Every changed file ties to the finding | Unrelated files or tests changed |
| Tests | A test fails before and passes after, and no tests were weakened | Tests deleted, loosened or mocked away |
| Data accuracy | Versions, package names and advisory facts verified at source | Facts taken from the assistant unchecked |
| Side effects | Behavior changes for users are listed and acceptable | Unknown or unreviewed behavior change |
| Evidence | Rescan and reproduction attached | Nothing attached |
| Rollback | Revert is one commit and the owner is named | No clear way back |
Reading the total
Maximum is 14. Here is a suggested use, which you should tune to your own risk:
- 12 to 14 with no zeros: normal review, merge when approved.
- 8 to 11, no zeros on the first three rows plus data accuracy: ask for specific fixes, then re-score.
- Any zero on root cause, tests or data accuracy: do not merge. Rework or write it by hand.
- Below 8: reject and record why.
Those thresholds are our suggestion, not an industry standard. The point is consistency.
Where each criterion comes from
The scope and tests rows reflect failure modes that OWASP's guidance on secure coding with AI describes: out of scope edits that reviewers miss, and tests deleted or weakened to make CI pass. The data accuracy row reflects its warning that assistants can suggest outdated versions with known CVEs and package names that do not exist.
Tips for using it
- Score before discussing, so the first person to speak does not set the number.
- Keep the scorecard in the pull request template, one line per criterion.
- Look at the zeros, not the average. A fix with perfect scope and no tests is still not ready.
- Review the pattern monthly. If data accuracy keeps scoring zero, tighten how versions are verified.
See what to check before merging a fix PR for a reviewer oriented checklist that pairs well with this rubric.
Safeguard's fix pull requests are off by default with every category on Manual, and policies and gates can enforce some rows automatically, such as required checks. Others, like root cause, remain a human call.
Quick check
Should the scorecard apply to human written fixes too?
Yes. The criteria are not specific to AI. They matter more for AI suggestions because the cost of generating a plausible change is so low.
Who should score?
The code owner reviewing the change. For sensitive areas, add a second reviewer from security.
Sources
Last reviewed: 19 October 2026.
