I’m working on an open-source tool called deadair that checks whether SIEM detections still have the telemetry they depend on.

The problem it catches is when a rule is still enabled and scheduled, but the data behind it has gone stale, stopped shipping, changed schema, or arrives too late for the rule window.

Today it only supports Elastic Security and OpenSearch Security Analytics. There is no Microsoft Sentinel adapter yet. I don’t want to build one from docs and toy KQL and then pretend it works.

For Sentinel, I’m trying to understand what a useful read-only model would need to handle before anyone would trust the output.

The rough model is:

analytic rule -> KQL dependencies -> tables/functions/watchlists/workspaces -> table freshness/schema/volume health

The parts I’m unsure about are real-world Sentinel details:

- KQL that hides table dependencies behind functions

- ASIM parsers

- watchlists

- custom tables

- cross-workspace and cross-tenant queries

- scheduled vs near-real-time rule behavior

- what read-only permissions a SOC or MSSP would actually approve

I’m looking for Sentinel operators, detection engineers, or MSSP folks who can sanity-check the design. Best case would be someone willing to run an early build later in a test workspace or limited-scope tenant. Redacted examples of rule/query patterns would also help.

Current repo, for context: https://github.com/Big-Comfy/deadair

Sentinel design issue: https://github.com/Big-Comfy/deadair/issues/3

If you run Sentinel day to day, what would this need to understand before you’d trust a “this detection has no usable telemetry” finding?