Detection verification · Read-only
Your coverage looks complete. That's not the same as coverage that fires.
A share of the detections you already run are silently dead: enabled, green in the console, and structurally unable to fire. Dectyl adjudicates every rule in your SIEM against the reality of your telemetry, read-only, and tells you exactly which ones, why, and how long they have been that way.
The question your board will ask is no longer "do we have detections for this?" It's "which of these can actually fire, and how do you know?" Almost no one can answer that with evidence.
Read-only. Nothing installs. No log data leaves your environment.
Coverage on paper isn't coverage that fires.
Detection rules die silently. A log source drops. An agent update renames a field. A lookup table goes stale. A shared macro gets edited. The rule stays in your console: deployed, green, quiet.
A rule can be mapped to a technique and still be unable to fire: the log source is missing, or the enrichment is dead. On every coverage heatmap that rule is a green cell. The heatmap cannot tell the difference.
Here is the trap. In the SOC, silence is the success state. A well-written rule rarely fires. So a dead rule and a healthy one look identical, and there is no alarm for the difference. Ingestion monitoring tells you the pipes are flowing. It cannot tell you the rules downstream still work.
SIEMs are sold on what they collect, never on what they can detect.
Your SIEM vendor has no incentive to grade its own detections. Someone independent has to.
This isn't only Dectyl saying it.
Independent industry research · 2025
A 2025 study analyzing more than 13,000 production detection rules across enterprise SIEM deployments found that roughly 13% were silently broken: enabled, green in the console, and structurally unable to fire. The same study found close to 79% of MITRE ATT&CK techniques sat unmonitored.
No console surfaces this on its own. It shows up only when someone checks every rule against what the environment can actually produce, which is the check Dectyl runs against your full rule set, not a sample.
Every rule. One verdict. Receipts included.
Dectyl adjudicates your entire detection rule set against the reality of your telemetry and returns one of three verdicts per rule.
The adjudication runs against a representation of your detection stack (rules, log sources, enrichment tables) inside your environment. Read-only.
We reason over that model to determine which detections can actually fire, dependency by dependency.
You get a concrete list: these rules can't fire, and why. You can verify every finding yourself.
Every dependency verified present: log source ingested, fields live, lookups resolving.
Structurally dead, with the exact reason: the missing sourcetype, the renamed field, the broken macro. Evidence your engineers can check in under two minutes.
We could not resolve it, and we say so. No verdict without evidence. Ever.
The output is a report your detection engineers will trust and your CISO can put in front of the board: what can fire, what can't, why, and what to fix first.
Don't take our word for it. Check five rules by hand.
Pick the five rules you are counting on most. For each one, run three searches. Paste them as written.
Take the index and sourcetype the rule searches, then:
| tstats count where index=<INDEX> sourcetype=<SOURCETYPE> earliest=-7d by _time span=1d
Empty result, or days at zero: everything downstream of this source is dead.
Take the table the rule queries, then:
<TableName> | where TimeGenerated > ago(7d) | summarize events = count() by bin(TimeGenerated, 1d)
Empty result, or days at zero: everything downstream of this table is dead.
Run the rule's base search (index/sourcetype only, no conditions), then:
index=<INDEX> sourcetype=<SOURCETYPE> earliest=-24h | fieldsummary | search field IN (<every field the rule filters or stats on>) | table field count distinct_count
Any field missing from this table, or at count 0: the rule can no longer match what it was written to match.
Run once per field the rule filters or aggregates on:
<TableName>
| where TimeGenerated > ago(24h)
| summarize total = count(),
populated = countif(isnotempty(<FieldName>))
Populated at zero while total is high: the rule can no longer match what it was written to match. Schema-level checks like getschema show the column exists even when nothing populates it, which is exactly the trap.
index=_internal sourcetype=scheduler savedsearch_name="<RULE NAME>" earliest=-90d | stats sum(result_count) as results_90d count as runs_90d
Runs high, results zero: the rule executes on schedule and has matched nothing in ninety days. It might be healthy and quiet. It might be dead. The point is that this check cannot tell you which. That is the difference between monitoring and verification, and it is why check 3 needs checks 1 and 2, and why your rule set needs Dectyl.
SecurityAlert | where TimeGenerated > ago(90d) | where AlertName == "<RULE NAME>" | summarize alerts_90d = count()
Zero alerts over ninety days: the rule might be healthy and quiet. It might be dead. The point is that this check cannot tell you which. That is the difference between monitoring and verification, and it is why check 3 needs checks 1 and 2, and why your rule set needs Dectyl.
SentinelHealth can confirm the rule is running, but only with health diagnostics enabled. A footnote, not a dependency.
If every check passes, you don't need us. If one fails, you have found a dead rule your console has been calling green, and you have the evidence in hand.
That is the scope conversation. Nothing else needs to leave your environment.
Different stack? Reply with your SIEM and the five rules. We'll send you the equivalent checks.
Built to survive your security team's scrutiny.
No agents, no appliances, no attack simulation, no code executing in your environment. Verification without simulation: nothing executes, nothing risks production.
Adjudication needs rule logic and telemetry metadata, never your logs.
Dectyl does not retain your rules or your verdicts. Your continuous detection assurance is yours alone.
Now scheduling August pilots.
A free three-week read-only pilot: your full rule set adjudicated, every verdict backed by checkable evidence, delivered as a board-ready report. You keep the only copy.
The engagement runs the way assessments your team already accepts do: scoped up front with success criteria in writing, read-only throughout, three weeks end to end, a report your engineers can check and your CISO can sign.
If the report finds nothing your team didn't already know, you've spent three review calls and gained a board-ready attestation that your rules can fire: signed evidence, not absence of bad news.
Pilots run one at a time, three weeks each. Requested this week, the report is in your hands before your next board review, backed by the same evidence bar as the research in Finding 02.
No call required. The email is pre-filled. Scope by reply.