A rule on 60% of hosts is 60% coverage
Coverage usually gets counted in rules written. The number that matters is what share of the estate each rule actually runs on.
Writing a rule and running a rule are different achievements, and coverage reporting tends to count the first one.
A detection evaluates wherever its agent is installed, healthy, and permitted to act. Every one of those has a failure mode. Agents crash and stay crashed. Someone adds an exclusion for a performance problem in March and nobody removes it. A build of an operating system is unsupported. A subnet of machines was provisioned by a team that never got the policy, and nothing in the console is looking for machines that are missing.
So the honest coverage figure is not how many rules you wrote. It is, for each rule that matters, the share of relevant hosts where it is genuinely evaluating.
Those two numbers can be far apart, and only one of them describes what an attacker would experience.
The uncomfortable version is that the gap is usually not random. Machines missing their agent are disproportionately the odd ones: old, unmanaged, built by somebody in a hurry, sitting in a corner nobody owns. That is also where an attacker prefers to be.
Take one detection you would name in a board report. Count the hosts it should cover, then count the hosts where it actually runs. Report the second number.
CHECK YOURSELF
Your platform reports that 100% of planned detections are deployed. What does that number not tell you?
SHOW THE ANSWER
Which hosts are actually running the agent that evaluates them
Why. Deployment percentages are almost always counted against the rule set rather than against the estate. A rule can be fully deployed in that sense while evaluating on a fraction of your machines, because agents fail, exclusion groups exist, some operating system versions are unsupported, and some hosts never received the policy. The other three are real questions and none of them is the gap this particular number hides.