Every SOC has one. A 140-line KQL rule with four joins, a nested case(), a hardcoded allow-list of hostnames from a reorg that happened in 2021, and a comment that says // DO NOT TOUCH - ask Dave. Dave left. The rule still fires. Nobody knows why. Congratulations, you are running archaeology in production.
Write-Only Detection Engineering
The industry spent a decade building tools to write detections faster. Editors, templates, rule generators, AI copilots that spit out queries on demand. Almost nobody built anything for the part that comes after: a human sitting in a review meeting being asked to approve logic they cannot read. So they approve it. Peer review becomes a thumbs-up emoji on a wall of pipes and parentheses. We already roasted that theater; this is the other half of the problem.
Logic that accretes complexity becomes private property of whoever touched it last. That is not an engineering practice. That is a hostage situation with a git history.
Enter the Logic Deconstructor
HEFAISTOS has a page for exactly this, and it is called, with zero marketing polish, Detection Logic Deconstructor. You paste a detection rule (the input hint literally says KQL, SPL, WAZUH) or give it a rule URL, pick the AI model you want, and hit Run Deconstruction. The point is not to run the rule. The point is to make it inspectable: what is it actually doing, which branches matter, what assumptions are buried in there.
- Bring your own model. There is no blessed vendor. You type any provider model name into the field and save it. Out of the box the page admits your selected model is “Not set”. Honest, if nothing else.
- Multi-format on purpose. Because real estates are not single-language. Your Sentinel KQL, your legacy Splunk SPL and your Wazuh rules all end up in the same review queue, and the reviewer should not need three dialect dictionaries.
- It sits between “implemented” and “approved”. Rule Hub holds the artifact, Workbench Detail is where it got engineered, and review is where somebody finally has to understand it. That is where this page earns its keep.
The Part Where We Are Honest
The page warns you, right under the heading, that AI prompts may be subject to charge. That is your provider bill, not ours, and yes, pasting rule text into an external model is a data-handling decision you should make deliberately, not by accident because a button was shiny. Also: an AI explanation is an aid to a human reviewer, not a replacement for one. If your process becomes “the model said it’s fine”, you have invented a more expensive rubber stamp.
We also verified the page and its inputs against the live UI; we are not going to pretend we have a benchmark proving explanation accuracy across every cursed rule ever written. If someone hands you a number like that, ask to see the test set.
Why Broad Rules Need It Most
Precise detections are usually short enough to read. Broad, behavior-driven analytics are the ones with the joins, the enrichment, the heuristics, and the thresholds that someone tuned on a Thursday. Those are the rules that generate the alerts everyone ignores, because nobody can tell which clause is producing the noise. Decompose the logic and suddenly “this rule is noisy” becomes “this one branch is noisy”, which is a sentence you can actually act on. Tuning without understanding is just guessing with a change ticket.
The Point
If your platform helps you create logic but cannot help you explain it, review it, or recover its intent after entropy has vandalized it, you did not build a detection engineering platform. You built a rule landfill with a nice editor. Paste the cursed rule in. Find out what Dave was thinking.
Happy hunting.
Featured image generated using Artificial Intelligence (EU AI Act transparency notice).