You've built a skill that hunts for beaconing. It queries your preprocessed candidates, scores them against a statistical rubric, checks whether the destination is a known Living Off Trusted Sites domain, pulls threat intelligence on the IP, examines the process ancestry, and produces a severity verdict. It works. You're happy.
Then you build a skill for DNS tunneling detection. It also needs to check LOTS domains — tunneling frequently abuses trusted services. So you copy the LOTS lookup logic into the new skill. Then you build a skill for C2-over-HTTPS, which also needs LOTS checks. And one for data exfiltration, which needs them too. Now you have LOTS domain logic duplicated in four skills, each maintaining its own copy of the domain list.
Then the LOTS landscape changes. Discord adds new API endpoints that adversaries are abusing. Notion gets weaponized for C2 payload hosting. You need to update the domain list — but it lives in twelve different skills, each with slightly different implementations. Some check against a hardcoded list, others query a file, one does a regex match. Updating "the LOTS list" means updating twelve skills, testing twelve skills, and hoping you didn't miss one.
This is the monolithic trap. When a single skill handles pattern detection AND contextual enrichment AND multi-signal correlation, every piece of shared logic gets duplicated across every skill that needs it. The duplication is bad enough. The maintenance burden is where it kills you.
There's a cleaner design. Three layers, each with one job, each consuming the output of the layer before it: detection, enrichment, correlation.
Where these layers sit
If you've read my previous lesson on distillation before deduction, you know that raw telemetry needs deterministic preprocessing before any agent touches it. Your preprocessing layer ingests, normalizes, harmonizes field names, computes statistical features, and produces scored candidates. That's the foundation.
The three layers in this lesson sit on top of that foundation. They're what you do with the preprocessed candidates — how you analyze them, add context, and synthesize findings into actionable assessments. Think of it as two distinct stages: preprocessing gets the data ready, and the three-layer architecture gets the analysis right.
Each layer has a clear input, a clear output, and a clear responsibility. No layer needs to understand the internals of any other — it just consumes the previous layer's output format.
Layer 1 — Detection
Detection is where signal emerges from noise. Every skill in this layer answers exactly one question: "Is this specific adversary behavior present in my telemetry?"
No enrichment. No correlation. Just finding patterns.
A detection skill takes preprocessed candidates as input and produces findings with a base score as output. That score reflects how strongly the data matches the adversary pattern the skill is looking for — nothing more. The detection skill doesn't know or care whether the destination IP has a bad reputation, whether it's 3am, or whether six other detection skills also flagged the same host. All of that context comes later. Detection skills are deliberately narrow.
Consider a beaconing detection skill. It queries your preprocessed beacon candidates and scores each one against a multi-part rubric — statistical regularity of connection intervals and payload sizes, jitter analysis (adversary-generated timing variation is statistically distinct from genuine human variation, so the jitter itself becomes a signal), and timing patterns relative to business hours. These components add up to a base score. But the detection skill stops there. It reports "here's a candidate with a concerning score" and moves on.
Detection skills span the full range of adversary behavior — beaconing, DNS tunneling, C2-over-HTTPS, data staging, lateral movement, credential dumping, process injection, persistence mechanisms, living-off-the-land techniques. Each skill is narrow. Each one looks for one thing.
The design principle that makes this work is independence. Your beaconing skill knows nothing about your DNS tunneling skill. They don't share state, they don't communicate, and they don't depend on each other's output. This independence is what makes parallel execution possible — you can run every detection skill simultaneously, each focused on its own question. A bug in one can never break another. A slow skill can never bottleneck the others. And you can add new detection skills without modifying existing ones.
Layer 2 — Enrichment
If detection is the blood test — targeted diagnostic measurements producing numbers — then enrichment is the medical history. It doesn't run new tests. It adds context that changes how you interpret the results you already have.
Enrichment skills are deliberately thin. No detection algorithms, no pattern-matching logic, no statistical analysis. Each one answers a single contextual question and adds points to a candidate's score.
The key word is "adds." Enrichment scoring is purely additive. It can pile on additional evidence, but it can never reduce a detection score. If enrichment could subtract points, you'd create situations where a detection skill says "this looks like beaconing" but an enrichment skill says "actually, never mind." By keeping enrichment additive, the interpretation stays simple: detection found something, and enrichment either confirmed it further or stayed silent.
Here's what enrichment skills look like in practice.
LOTS enrichment checks whether the destination is a Living Off Trusted Sites domain — services like Mega.nz, Pastebin, or GitHub raw content that adversaries abuse for C2, payload delivery, and exfiltration. One LOTS domain is another Tuesday. Three across three abuse categories is a possible campaign.
Time enrichment examines when the activity occurs relative to business hours — connections at 3am score higher than connections at 2pm. Reputation enrichment checks whether threat intelligence knows about the destination. Geographic enrichment looks at whether the destination is anomalous for the organization.
Baseline enrichment asks: have we seen this before? A process making outbound connections on port 443 is ordinary. That same process making those connections when it's never done so in 90 days of baseline data is extremely interesting. Novelty — the absence of historical precedent — is one of the strongest signals in threat hunting, and this enrichment quantifies it.
Each enrichment skill maintains its own logic, its own data sources, and its own scoring model. Update the LOTS domain list, and every detection finding that passes through LOTS enrichment gets the benefit. You update one skill, not twelve.
Layer 3 — Correlation
Detection finds individual signals. Enrichment wraps context around them. Correlation is where it all converges into a diagnosis — taking the test results and the medical history and producing an assessment.
A correlation skill consumes the outputs of multiple detection and enrichment skills, combines their scores, and produces a unified threat assessment. Where detection asks "is this pattern present?" and enrichment asks "what context surrounds it?", correlation asks: "do these patterns, taken together, tell a coherent story of adversary behavior?"
Consider a correlation skill looking for the complete arc of command-and-control establishment. It consumes beaconing detection, C2-over-HTTPS detection, LOTS enrichment, and process-tree analysis. Each input arrives with its own enriched score. The correlation skill combines them into a composite that maps to a severity tier.
The power is in what correlation catches that individual skills can't. A beaconing finding by itself is maybe worth a look, maybe not. A suspicious process tree by itself is the same. But those two signals pointing at the same host, at the same time, with LOTS enrichment and suspicious HTTPS patterns? That's not two moderate findings. That's a critical incident where individual pieces of evidence reinforce each other into a coherent attack narrative. The correlation skill packages this with the contributing findings, the timeline, the affected hosts, and a recommended investigation path — every score traceable to the detection and enrichment skills that produced it.
Other correlation patterns follow the same design — exfiltration chains, lateral movement chains, intrusion chains. Each one is essentially an attack story template. It knows what the components of a specific adversary campaign look like, and checks whether the current evidence fits.
The maintenance dividend
The payoff of layered architecture shows up about six months in, when your system has grown from five skills to fifty.
A new threat intelligence feed becomes available. You update the reputation enrichment skill. Every detection finding that flows through it — from every detection skill you've ever written — gets the benefit automatically. A new adversary technique emerges. You write one new detection skill. It immediately inherits all existing enrichments without you writing a single line of enrichment logic. A LOTS domain list update arrives. One file changes. One skill picks it up. Every detection finding across your entire system gets the updated scoring.
Each layer evolves independently. New detection skills don't require new enrichment logic. New enrichment sources don't require detection skill changes. New correlation patterns compose from existing outputs without modifying either.
Three layers with clean separation. No duplication. And every update happens in exactly one place.