A detection is not an alert
Signal, detection, alert and case are four different things, and teams that use the words interchangeably end up measuring the wrong one.
Four words get used as if they mean the same thing. They do not, and the confusion shows up in the metrics.
A signal is raw telemetry. A process started. A token was issued. Nobody has decided it means anything.
A detection is logic matching a signal. Your rule fired. This says nothing about whether a human should care.
An alert is a detection that reached a person. Everything between the detection and the alert is your pipeline deciding it deserved attention: deduplication, enrichment, suppression, risk scoring.
A case is an alert somebody opened and worked.
The gaps between those numbers are where your programme actually lives. A rule matching four hundred times a day that produces twenty alerts is not a noisy rule; it is a rule with good pipeline behind it. The same rule producing four hundred alerts is an emergency.
This matters most when someone asks how many alerts you get. If you answer with detections, you sound overwhelmed. If you answer with cases, you sound idle. Neither number tells them what they wanted to know.
Next time you report volume, say which of the four you are counting.
CHECK YOURSELF
A rule matches 400 times a day. Nobody looks at 380 of them because they auto-close on a known-good process. What is the honest count to report?
SHOW THE ANSWER
400 detections and 20 alerts
Why. The rule matched 400 times, so there were 400 detections. Only 20 reached a human, so only 20 were alerts. Reporting 400 alerts overstates analyst load, and reporting 20 detections hides how much the rule actually matches, which is the number you need when you tune it.