The point up front: Every detection is actually three artifacts, not one. The rule logic, the tuning decisions, and the operational context. Most SOC teams document only the first. When the other two live in someone’s head, your institutional memory has a countdown timer on it. The fix is a single, version-controlled config artifact per rule that captures all three.

Here’s the argument.

The Problem: One Rule, Three Artifacts, One Documented

A detection rule made it to Sentinel during a migration. The logic was sound. The tuning wasn’t. Thresholds and exclusions refined over 18 months of live operation were copied as hardcoded values. No documentation. No reasoning. No record of the conditions they depended on.

Within days, alert volume spiked. The SOC couldn’t separate signal from noise. Real detections got buried. Months later, when a new engineer needed to re-tune the rule, nobody knew why the original values existed. She spent weeks reverse-engineering decisions that had already been made once, by someone who was paid to make them, who wrote them down nowhere.

That failure happened because the team treated the detection as one artifact. It’s three:

1. Rule logic: the pattern you’re hunting. Five failed logins in two minutes. This is the detection premise. It’s the part that lives in the rule itself, and it’s the only part most teams document.

2. Tuning decisions: the operational choices that make the logic work in your environment. Threshold set to five because four generated noise from legitimate behavior. Service account excluded because it fails logins during batch jobs. Time window set to two minutes because that’s how fast real attacks escalate.

3. Operational context: the infrastructure conditions that make the tuning valid. Which table the rule queries. What storage tier it runs against. Ingestion latency. Upstream DCR filtering. ASIM schema dependencies. Query cost at scale.

These three are mutually dependent but separately owned. Lose the logic and you lose the detection. Lose the tuning reasoning and you lose the decisions. Lose the operational context and you lose the conditions under which those decisions were ever valid. A threshold of five makes sense against hot tier data with five-minute latency. It fails against cold tier data with a two-hour lag. Same number, same rule, broken detection. The rule will not send a notification about this.

Why Now: Three Forces Compounding the Loss

This has always been a risk. Three things make it acute right now.

1. People are leaving faster than knowledge is captured. Layoffs have thinned SOC teams. The engineers who made the tuning decisions are gone. What they knew walked out with them, and the documentation debt they left behind compounds with every departure.

2. Detection-as-code makes changes visible but not explained. DCRs, KQL in repos, infrastructure-as-code pipelines. You can see that a threshold changed in the commit history. You cannot see why. The commit message says “updated threshold.” Very helpful. Visibility without reasoning is a false sense of security.

3. Detection is scaling faster than documentation practices. Automation and AI tooling are multiplying rule counts and config changes. Every undocumented change is debt. The volume of debt is growing faster than any team’s capacity to pay it down manually.

Each force is independent. Together, they mean the migration story above stops being an edge case and becomes the default outcome.

The Fix: One Artifact Per Rule, Three Sections

Create a config file per detection rule. Version-controlled, living alongside the rule itself. Three sections, mapping directly to the three artifacts.

Section 1: Operational context (the conditions the rule depends on)

• Data source and table (CommonSecurityLog, SecurityEvent, etc.)
• Storage tier and retention
• Expected ingestion latency
• DCR and upstream filtering that shapes what data arrives
• ASIM schema dependencies, including any vendor-specific fields
• Approximate query cost and performance constraints

Section 2: Tuning decisions (the choices made within that context)

• Threshold value, when it was last changed, and by whom
• The reasoning: what incident, noise pattern, or analysis produced this value
• Each exclusion, its reasoning, and the conditions under which it stops being valid
• The dependency: which operational context items this tuning assumes stay true

Section 3: Change log (the memory itself)

• Date, author, what changed, why
• Not the git diff. The reasoning behind the diff. The part that currently lives in a Slack thread from 2024 that nobody can find.

That’s it. No new tooling. No platform lift. The structure matters less than the consistency. What matters is that every decision and every dependency exists somewhere other than a person’s head.

The Test: Three Questions Against Your Oldest Rule

Audit one rule this week. Pick the detection that’s been in your environment the longest, and ask:

1. Could someone else understand why the threshold is set where it is, without asking you?
2. Could they re-tune it safely if the operational conditions changed, knowing which constraints have to stay true?
3. If they had to rebuild it tomorrow, how much of your knowledge would they waste time rediscovering?

Any “no” means the knowledge is already lost. You just haven’t been forced to notice yet. The next migration, reorg, or departure will handle that part on your behalf.

Three artifacts. One config file. Start with one rule.