400 of your SOC's 900 detection rules have never fired - what does that entitle you to conclude?

## Silence is a measurement with several causes 'Never fired' is one observation with at least five explanations, and they demand different responses. At 400 rules you cannot open them individually, so the job is to sort the tail into buckets using data you already have. **1. It was never really running.** The rule exists in the console but is disabled, scheduled and erroring, saved as a draft, or deployed to one tenant and not the others. This is a deployment fact, not a detection fact, and it is usually the largest bucket in a portfolio nobody has audited. The discriminator is the rule's own execution metadata: did it execute, not did it match. **2. The telemetry never arrives.** The rule queries a source or an index this estate does not onboard, or references a field the parser here does not populate. A rule watching for a command line on a platform where command-line capture was never enabled will execute happily forever and match nothing. The discriminator is a schema check: does every field this rule filters on appear in real records from this estate in the window? **3. The behaviour genuinely does not occur.** A rule for a cloud service you do not use, a database engine you retired, an operating system nobody runs. This is an **honest zero** - the rule is fine and there is nothing to see. The discriminator is asset inventory, not the rule. **4. The behaviour occurs and the logic cannot match it.** Over-constrained conditions, a field renamed by a platform upgrade, a value the vendor now writes in a different case. This is the dangerous bucket because it is the one that looks identical to bucket three from outside. Telling one broken rule from a genuinely quiet estate is a per-rule investigation and it is a different job from this one - what portfolio partitioning does is shrink the candidate list from 400 to something a person can actually work. **5. It fired but never opened a case.** If you counted in cases rather than firings, rules that only ever corroborate somebody else's alert appear in the never-fired column. That is a counting artefact, and it is why the last-fired timestamp from execution metadata belongs in the table beside case counts. ## The inference limit, which is the real answer Whatever the partition says, the tail cannot be converted into a statement about your exposure. A detection produces output when it matches and produces nothing otherwise, and *nothing* is exactly what a quiet estate produces too. The two are indistinguishable in the data. That has a hard consequence: **the false-negative rate of a detection portfolio is not computable from the portfolio's own output.** You can measure precision over things that fired. You cannot measure recall over things that did not. This is what separates a detection from most other rules an organisation runs. A gate that blocks changes can be replayed against captured inputs and you can watch what it decides. A detection's input is the adversary's behaviour, and replaying a stored record only proves the parser and the query still work on that record. **The only evidence that a silent detection still works is executing the behaviour it claims to catch in the estate and confirming the alert appears** - emulation, a purple-team exercise, an authorised test of the technique against a real host with real telemetry. Absent that, a green rule in a console is an assertion, not a measurement. ## The reporting risk A leader shown '900 detections' reads 900 protections. The tail is where the gap between that impression and reality lives, so a content review that reports rule counts without reporting the never-fired share is producing a misleading number even if every individual figure in it is accurate. Reporting the partition - deployed but silent, no telemetry, no such assets, unexplained - converts an embarrassing statistic into an actionable one. ## What this does not decide Partitioning the tail tells you which rules are silent and roughly why. It does not tell you which to remove, and the temptation to convert a long tail straight into a deletion list is exactly where portfolios go blind: every removal is a decision about what you accept not seeing, and that decision has to be priced separately from the measurement that surfaced it.