Most detection rule catalogues answer one question: what pattern should fire an alert? Fewer answer the question that actually determines whether the rule works in production: does your environment even produce the log fields this rule depends on?
That gap is where a lot of "we have a SIEM with 400 rules" deployments quietly fail. A rule can be syntactically perfect and still never fire — not because the attack didn't happen, but because the audit policy that would have populated TargetSid or AuthenticationPackageName was never turned on. Sigma made rule portability solvable. It didn't solve the "is my logging even sufficient" problem, and that problem is arguably the more common failure mode.
The actual on-call question
When someone gets paged on an Event ID, the real question isn't "what does 4625 mean" — that's a lookup table. It's a chain of three questions:
- What rule(s) actually depend on this event ID?
- What fields does each rule need from it?
- Is my environment's audit policy actually configured to populate those fields?
Every rule in this catalogue carries the answer to all three, explicitly, next to the detection logic itself — not in a separate wiki page that drifts out of date. required_fields and audit_policy are first-class parts of the rule, not documentation bolted on after.
Why false positives get the same billing as the detection logic
A rule without documented false positives isn't more confident — it's less trustworthy, because it implies nobody thought about how it fails. LIN-2001 (SSH Brute Force) will fire on a misconfigured automation job retrying stale credentials just as readily as on a real spray. That's not a flaw in the rule; it's a property of threshold-based detections that needs to be visible at the point someone decides whether to trust the alert, not discovered three false-positive tickets later.
Why this matters more once you chain rules together
A single rule is a tripwire. A chain of rules across a full attack lifecycle is a story — and the individual stages in that story are almost always unremarkable on their own. That's the actual argument for treating "does my logging support this rule" as seriously as "is this the right detection logic": a five-stage chain is only as strong as its weakest stage's audit policy.