Two formats, on purpose
Sigma is for detections that must move. Platform-native query languages are for detections that must run fast on a specific backend. These goals genuinely conflict, and picking one costs you something real.
I keep both. Sigma is the source of truth and the thing that survives a platform migration; the native rule is the compiled artifact, tuned where volume demands it. In ARGOS that shows up as a Sigma rule set covering everything from Kerberoasting to DCShadow, alongside an SPL library for the Splunk side.
The failure mode is keeping only the native version. It works beautifully until a migration, and then you discover your detection logic was never written down anywhere a human could read.
Detections are code, and nobody tests them
A rule that has never been fired against a known-true event is a hypothesis, not a detection.
Every rule needs a test case that should trigger it and a test case that should not. Run them in CI. This is unremarkable engineering practice that detection content is routinely exempted from, and the result is rule sets nobody trusts enough to tune.
Retirement is the neglected half
Detections accumulate. A rule that has not fired in ninety days is telling you something: either the threat stopped being relevant to you, or the rule broke and nobody noticed. Both need action. Neither gets it, because deleting a detection feels like reducing coverage.
It usually is not. A rule that cannot fire has no coverage to reduce. It has upkeep cost, query cost, and a line in a report that makes you feel covered.
Flag the silent ones. Make someone justify keeping them.
On coverage numbers
You will see claims about what percentage of ATT&CK techniques the average organisation detects. Treat them carefully — coverage depends on which techniques are reachable in your estate, and a technique that does not apply to you is not a gap.
Use ATT&CK as a shared vocabulary so that your detection, your threat intel and your report are describing the same behaviour. Use it as a scorecard and you will end up writing rules to raise a number.
Where a model helps
Not writing rules. Explaining anomalies.
A behavioural baseline can tell you this service account has never touched this host. That is useful and it is not new. What a model adds is the sentence after it — what would have to be true for this to be benign — which is the question a good analyst asks and a tired one skips.
That is a real improvement, and it is much less exciting than it sounds in a vendor deck.