When you fix false positives from a monitoring instrument (error reporter, watchdog, alerter) by adding suppression logic, silence alone is an ambiguous acceptance signal: it could mean the fix is working OR the instrument died entirely. The fix is indistinguishable from a regression without a control signal.
Pattern: identify or create a known-valid population that exercises the same code path but should NOT be suppressed. That population's continued firing is positive evidence the instrument is alive and the silence on the noisy population is genuine suppression, not breakage.
Concrete example: a JS freeze watchdog (setInterval gap detector) produced 320 events in 3 days, ~89% from browser background-tab timer clamping (false positives). The fix added visibility and clock-jump guards. After deploying, the web issue (FF-FRUIT-18S) went to zero events. But a sibling issue on Android WebView (FF-MOBILE-V), running the exact same watchdog code on the same release, kept firing with real 3-5s freezes. That continued firing is the proof: the watchdog is alive, the guards are selective, and the web silence is real suppression rather than a dead instrument.
Without the control: zero events on 18S for 48 hours could also mean the watchdog's heartbeat stopped for an unrelated reason (e.g., a deployment broke the module load, or the setInterval never started). The control population rules that out in a single API call.
Generalizes to: Sentry beforeSend filters (keep a tagged residual), alert-rule suppressions (keep a canary source), log-level downgrades (keep one logger at the original level), and rate-limit filters (keep a known-hot path ungated). The control population should be as similar as possible to the suppressed one, differing only in the property the fix gates on.