Detection is a system, not a model
The tempting mental model is that you buy or build a detector, switch it on, and problems now announce themselves. Every part of that is wrong. The detector needs a threshold that reflects your costs, its idea of normal decays as your business changes, its alerts are worthless unless a human trusts and acts on them, and left fully automatic it can quietly stop learning what normal even looks like. This final leader session is about running detection as a living system - and knowing the times you should not automate it at all.
The threshold is a business decision 3 min live
Last session showed the sensitivity dial trades recall for precision. Here is the leadership point: choosing where it sits is not a model task at all - it is a cost decision, and it belongs to you. The only honest way to set it is to weigh the cost of a miss against the cost of a false alarm, in your context, and pick the operating point that hurts least.
LiveTwo costs, one operating point2 min▶
The two mistakes are rarely equal, and the ratio decides the dial:
- Cost of a miss - what a silent anomaly does. A missed outage is an incident and a headline; a missed fraud is money out the door; a missed defect is a recall.
- Cost of a false alarm - what a wrong flag does. A frozen customer card, a woken engineer, a wasted investigation, and a little more of the team's trust spent.
When misses dominate, tune sensitive and accept the noise. When false alarms dominate, tune conservative and accept some misses. A model cannot make this call because it does not know your costs - so ask for precision and recall at a few settings, then decide.
A hospital vitals monitor and a marketing-email spam filter sit at opposite ends. The monitor tunes for recall - a missed crisis is unacceptable, so it tolerates many false alarms. The spam filter tunes for precision - one real email lost to the junk folder costs more than letting a little spam through. Same dial, opposite settings, because the costs are opposite.
Concept drift: normal changes 3 min live
A detector learns what normal looks like and flags departures from it. But normal is not fixed. A new marketing campaign lifts your traffic, a new product shifts your mix, a seasonal pattern arrives - and suddenly the detector, trained on the old normal, screams anomaly at things that are perfectly fine. This is concept drift, and a static detector rots into a false-alarm machine.
Self-studyWatching for drift without the math2 min read▶
You do not need to read a statistics dashboard to catch drift. Watch for the business signals:
- The alert volume climbs steadily even though nothing is actually breaking more often.
- Alerts cluster around a known change - a campaign week, a new feature, a holiday - and are all false.
- The team starts saying "ignore the spike, that's just the new normal."
Each is a cue to retrain the detector on recent data so its idea of normal catches up with the business. Monitoring the detector is as important as the detector itself - which is the last rung of the maturity roadmap below.
Human-in-the-loop, and the feedback trap 4 min live
For high-stakes flags, detection should triage for a human, not act on its own. The detector's job is to surface the suspicious few from the ocean of normal so a person can decide - and that person's decision (real, or false alarm) is precious feedback that makes the next round better. But automate too aggressively and you spring a subtle trap: a system that acts on its own flags can stop learning what normal even is.
LiveTriage for a human on high-stakes flags2 min▶
Detection rarely knows why something is odd - only that it is. For anything consequential, that means the right output is a prioritized queue for a human, not an automatic action:
- The detector ranks and surfaces the suspicious cases, with context.
- A human investigates and dispositions each one - real, or false alarm.
- That disposition feeds back as a label, sharpening the detector and letting you actually measure precision over time.
This is also how scarce, precious labels get created in the first place: through human investigation, arriving late but real. The human is not overhead - the human is the label factory.
LiveThe feedback-loop danger2 min▶
Here is the trap. Suppose flagged cases are automatically removed or auto-actioned - blocked, filtered, cancelled - with no human ever confirming them. Now the detector never learns whether it was right, and worse, it stops seeing the very cases it flags. Its picture of "normal" freezes or curdles, false alarms get treated as truth, and errors compound silently.
Auto-blocking is where this bites. A fraud system that auto-cancels every flagged transaction with no review never finds out how many were good customers - it just quietly loses them, and its sense of normal drifts toward whatever it has not yet blocked. Keep a human sampling the flags, or the loop closes on itself and you stop learning.
When NOT to auto-flag 4 min live
The most senior instinct in this whole track is knowing when to not build the automated detector. Detection has real costs - false alarms, engineering, trust - and there are situations where auto-flagging makes things worse, not better. Name these before you commit a team to building.
Self-study"A simple rule is enough" is a real answer2 min read▶
Do not let the appeal of a clever model talk you past a plain rule that already works. If "alert me when the value crosses this line" catches what you need, a machine-learned detector adds cost, drift risk, and false alarms for no gain. Reach for the ML detector only when the anomalies are contextual, collective, or shifting in ways a fixed rule genuinely cannot express. Starting simple is not timidity - it is the first rung of the roadmap.
Build vs buy, briefly 3 min live
You do not always have to build the detector in-house. Managed detection services exist for common domains, and the choice is a familiar leadership trade-off, not a technical one.
LiveWhen to buy, when to build2 min▶
- Lean toward buy when the problem is standard (common fraud, infrastructure metrics), you lack a data-science team, or you need it working next quarter. A managed service ships tuning, monitoring, and retraining you would otherwise build.
- Lean toward build when the anomalies are specific to your business, the data cannot leave your walls, or detection is itself a competitive edge worth owning.
Either way, everything in this track still applies - a bought detector still has a threshold you must set, drifts you must monitor, alerts a human must act on, and the same rare-event honesty about precision and recall. Buying moves the work; it does not remove your judgment.
A crawl-walk-run roadmap 4 min live
You do not deploy a monitored, retrained, human-in-the-loop ML detector on day one. You earn your way up. This is the staircase to take back to your team - each rung delivers value and sets up the next, and most orgs should start at the bottom left, not the top right.
LiveReading the staircase2 min▶
- 1 · Baseline threshold - a plain "alert past this line." Cheap, honest, the bar everything else must beat.
- 2 · Contextual / seasonal - remove the known pattern (weekday, season) before flagging, so you stop drowning in expected swings.
- 3 · ML detector + tuned dial - a real model for contextual and collective anomalies, with the sensitivity dial set to your costs.
- 4 · Human-in-the-loop + feedback - triage high-stakes flags to a person, and feed their dispositions back as labels.
- 5 · Monitored + retrained - watch the detector for drift and retrain it as normal moves. Detection as a living system.
Most organizations should honestly place themselves at rung 1 or 2. There is no shame in that - and skipping straight to rung 5 is how detection programs collapse under their own false alarms.
Try it yourself - this week ◐ 25-35 min total
- Pick one detection need in your org (real or planned) and place it honestly on the crawl-walk-run staircase - which rung is it on today?
- Draft a 4-step detection roadmap for it: name the next rung, the one after, and what each delivers. Keep it to four concrete steps a team could act on.
- For its threshold, write one line on the cost of a miss vs the cost of a false alarm - which dominates, and which way should the dial sit?
- Name one thing your org should NOT auto-flag, and why - low precision, fast drift, no one on call, over-automation, or "a simple rule is enough."
- Decide build or buy for it in one sentence, and note what still stays your judgment either way.
- Optional: revisit the Numenta Anomaly Benchmark's framing on streaming detection and why real-world evaluation must account for the human on the other end.
Sources covered (cited)
Taught from the anomaly-detection canon, framed for decision-makers. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Your detector's false-alarm rate has climbed for a month, but nothing is actually breaking more. The likeliest cause?
Normal is a moving target. A detector you never retrain rots into a false-alarm machine as the business changes. Monitor and retrain.
2 · For a high-stakes fraud flag, why route it to a human instead of auto-cancelling the transaction?
Human-in-the-loop turns flags into precious labels and avoids the feedback trap where an auto-actioning system stops seeing, and learning from, what it flags.
3 · Which is a legitimate reason NOT to build an auto-flagging detector?
Auto-flagging into low precision, fast drift, an empty on-call, or over-automation makes things worse. Sometimes a plain rule or human review is the right answer.