Adaptive Detection Governance: Defining the Missing Governance Layer in Security Operations

Why the next leap in SOC AI is not faster investigations, but fewer unnecessary ones.

Adaptive Detection Gobernance | Upstream vs Downstream

The future of AI in the SOC is not better investigations.

It is fewer unnecessary investigations.

That sounds almost too simple, but it points to a structural problem in the way security operations are currently being optimized.

Most of the market energy around AI in security is flowing downstream. Vendors promise faster triage, better enrichment, autonomous evidence gathering, more efficient incident handling, and more intelligent response. Those capabilities matter. They solve real pain. But they all begin from the same hidden assumption:

the alert stream is a given.

If the system already produces thousands of alerts a day, the question becomes how to sort them faster, investigate them better, and close them sooner.

That assumption is exactly where I think the industry has over-concentrated its attention.

In many environments, the more important question is upstream:

why do so many of those alerts exist in the first place?

The Market Is Optimizing the Wrong Layer

Alert fatigue is not a controversial problem.

False positives are well documented. Analyst burnout is well documented. Operational overload is well documented. The cost of spending human time on low-value alert investigation is well documented. Even the AI era is not dissolving those pressures. If anything, it is changing their economics: noisy environments no longer only burn analysts, they also burn storage, inference capacity, and token budgets.

The dominant market answer has still been to improve the downstream layer:

· triage faster

· investigate faster

· enrich more context

· respond automatically

That is understandable. It is easier to sell. It is easier to demo. It is easier to show on a dashboard. And it aligns with how most organizations experience the pain: they see queues, cases, escalations, burnout, and MTTR.

But the queue is not the whole system.

A large percentage of the noise in a SOC does not begin in the analyst workflow. It begins earlier:

· in telemetry that should never have been ingested that wa

· in parsers that do not preserve the fields detections depend on

· in rules that were written once and never re-governed

· in context that never made it into the detection path correctly

· in alert-generation logic that remains active long after its operational assumptions have changed

The result is a strange industry pattern: we keep applying more intelligence to the downstream treatment of alerts that a healthier upstream system would have reduced, re-routed, or never generated.

The Missing Upstream Layer

This is the gap I have been trying to define more clearly:

Adaptive Detection Governance (ADG).

I am not proposing ADG as a product launch, nor as a claim that no prior art exists. The space already contains serious adjacent efforts: Detection-as-Code, detection validation, Continuous Detection Engineering, posture assessment tooling, and rule-quality products. What remains fragmented is the upstream governance layer that ties those efforts together into a coherent, vendor-neutral capability model.

That is what ADG is meant to name and specify.

My working definition is:

Adaptive Detection Governance (ADG) is a vendor-neutral governance layer for continuously evaluating and improving the production quality of security signal across telemetry, parsing, detection logic, and alert-generation pathways.

That definition matters because it pulls the problem out of the narrow frame of “rule tuning.”

ADG is not only about changing a noisy rule. It is about governing the production quality of signal before downstream investigation spends human or machine effort on it.

This Is a Governance Problem, Not Just a Tuning Problem

Calling this a governance problem is deliberate.

If the problem were only tuning, the solution would be straightforward: assign someone to review noisy rules more often.

But real environments are more complex than that.

Detection quality is produced by the interaction of multiple layers:

· telemetry selection

· parser quality

· normalization fidelity

· rule logic

· business context

· operational validation

· feedback from actual investigation outcomes

That means you can have:

· a correct rule operating on incomplete parsing

· a good parser feeding low-value telemetry

· high-volume detections that are structurally aligned but contextually invalid

· clean detection logic trapped inside a vendor-specific enrichment model

· strong downstream triage trying to compensate for a poor upstream signal-production system

The governance problem is not just “how do I write better rules?”

It is:

· what should be detected

· from which sources

· under what quality constraints

· with what supporting context

· and how outcomes should change future detection behavior

That is broader than tuning, and it is why I think the layer needs a more precise name.

Why AI Makes This Newly Practical

There is a reason this layer has often remained fragmented or under-owned.

Historically, continuously governing telemetry, parser behavior, rule quality, and context pathways was expensive. It required discipline, engineering time, and organizational persistence that many teams did not have. Large enterprises could sometimes approximate pieces of it. Most organizations could not.

This is where AI actually becomes interesting.

Not because “AI will replace the SOC,” and not because every alert should be handled by a clever agent. The more useful shift is economic and operational:

AI can make continuous upstream governance more realistic at scale.

That includes things like:

· identifying structurally noisy telemetry patterns

· spotting parser drift or extraction gaps

· detecting duplicate or dormant rule patterns

· classifying whether a false positive is structural or contextual

· proposing governed changes with traceability

· helping maintain a portable knowledge base that survives tool changes

That is a very different role from asking a model to summarize an alert or produce a verdict over a case queue.

In other words:

AI is not the definition of ADG.

It is one of the reasons ADG has become newly practical.

Why Vendor Neutrality Matters

Another reason I think this needs a framework-level definition is that too much of the upstream space is still described in vendor-specific terms.

One product calls it posture management. Another calls it continuous detection engineering. Another bundles it into broader control assessment. Another treats it as validation. Another only covers the rule side and ignores telemetry routing or parser quality.

Those products can be useful. Some of them are solving meaningful parts of the problem.

But no single vendor implementation should define the layer.

A serious upstream governance model should remain portable enough that a CISO, detection engineer, or architect can ask:

· what capabilities do we actually have?

· what parts are missing?

· what is tied to this vendor?

· what survives if we change the SIEM, XDR, or enrichment path?

That is why ADG, as I am using the term, is capability-defined before it is product-defined.

The Layer Is Broader Than Rule Management Alone

The easiest place to notice the problem is in rules, because that is where operational pain becomes visible. Rules get stale. Logic drifts. Exceptions accumulate. Nobody remembers why something was added six months ago. Teams inherit detections from other teams and lose the context that justified them.

But the problem begins before the rule.

If a source is too noisy, if the wrong fields are parsed, if architectural context is trapped in the wrong place, or if investigation outcomes never feed back into upstream decisions, the organization will continue producing alert streams that downstream systems can only process, not meaningfully govern.

That is why the ADG specification I am developing spans:

· source-layer governance

· parser-layer governance

· rule lifecycle governance

· adaptive feedback loops

· external architectural knowledge

· observability and portability

This is not because every team needs a giant new platform tomorrow.

It is because the upstream problem is larger than any one artifact in the pipeline.

What ADG Is Trying to Contribute

I am not claiming that no one has seen the upstream problem before.

The stronger and more honest claim is this:

the problem is real, the adjacent efforts are real, but the layer itself is still not clearly specified in a vendor-neutral way.

That is the contribution I am trying to make with ADG:

· name the layer

· define its scope

· specify its minimum capabilities

· make it discussable independent of any one tool

If that helps organizations compare products more intelligently, compose their own stack more deliberately, or simply notice that they are over-investing in downstream treatment of upstream noise, then the framework is doing useful work.

Final Thought

The security industry does not have a shortage of ideas for investigating alerts faster.

What it still lacks, in too many places, is a disciplined way to govern whether those alerts deserved to exist at all.

That is the gap Adaptive Detection Governance is meant to address.

Not as a slogan. Not as a denial of existing tools. Not as a replacement for downstream AI.

As a framework for naming and specifying the upstream governance layer that healthier detection systems require.

The canonical specification and self-assessment live here:

GitHub: https://github.com/gromerosec/adaptive-detection-governance

Zenodo DOI: https://doi.org/10.5281/zenodo.20371975

— gromero-sec | Detection Engineering | github.com/gromerosec/