Teach the engine: mark false positive, confirm real

The de-noise heuristics get most calls right, but you know your environment best. When you correct a verdict, Perimeter remembers it and applies your judgement on every future scan.

1 · The two buttons

Expand any finding (Findings tab or Dashboard) to reveal its action buttons. Two of them drive the feedback loop:

Button	Use when…	Effect
Mark false positive	The finding is wrong — e.g. the version banner was misleading, or you’ve confirmed the service isn’t actually vulnerable.	Suppresses the finding even if the heuristics trusted it, and remembers the call.
Confirm real	The engine flagged it as likely-FP but you’ve verified it is real and exploitable.	Rescues it from heuristic suppression so it ranks normally, and remembers the call.

Click a button again to toggle it off (the label shows a ✓ when active, e.g. “✓ marked false positive”). Clearing a verdict returns the finding to the engine’s automatic judgement.

2 · Your verdict wins

A human mark overrides the heuristic verdict. This is deliberate: the suppression engine respects your judgement.

“Mark false positive” sets the verdict to suppressed (likely_fp) even if the heuristics — including KEV or multi-engine — would have trusted it. The reason trail records “user-confirmed false positive (suppression memory)” at the top, with the original heuristic reasons preserved below it for context.
“Confirm real” sets the verdict to trusted and clears any likely-FP flag, with the reason “user-confirmed real finding (suppression memory).”

Tip: because “Mark false positive” overrides even KEV/confirmed signals, use it only when you’re sure. If you just want to acknowledge a real risk you’re choosing not to fix yet, use Accept risk in the status workflow instead — that keeps the finding visible with an audit-logged reason and expiry. See Findings & de-noising and the comparison below.

3 · Suppression memory — it persists across rescans

Your verdict is keyed to the finding’s stable dedup_key (one canonical id per asset × check × engine), so it survives:

Page reloads — stored in your browser’s localStorage (key perimeter.findings.fp).
Future scans / re-ingests — when the same finding reappears in a new scan, your verdict is re-applied automatically; you never re-triage the same false positive twice.

Deferred / hosted In the cloud tier, suppression memory is per-tenant and syncs through the Keystone store so it follows the whole team and all of an MSP’s clients, not just one browser. Locally it lives in your browser only.

4 · Every mark is audited

Marking a finding FP or real writes an entry to the Audit log tab (action: “marked false-positive/real”), recording the verdict and the target finding. This matters for compliance: an auditor can see exactly what was suppressed, by whom, and that it was a deliberate decision rather than missing data.

5 · “False positive” vs “Accept risk” — don’t confuse them

	Mark false positive	Accept risk (status)
Meaning	“This isn’t actually a vulnerability.”	“This is real, but I’m choosing not to fix it (yet).”
Stays visible?	Suppressed / hidden under “Hide noise.”	Yes — shown as Risk accepted, with reason + expiry.
Needs a reason?	No (it’s a verdict on accuracy).	Yes — reason, approver, and expiry are required.
Audit entry	fp_feedback	risk_accept

Recover a mistake: accidentally suppressed a real finding? See Troubleshooting: a real finding got suppressed.