Anomaly Detection

Anomaly Detection refers to asking Claude to find items within a batch of data that clearly deviate from normal range, flag them, and attach a possible direction for the cause, serving as a starting point for further judgment. This is an act of locating a problem, not solving one — anomaly detection's output is a list of what differs from usual, not a conclusion about what's wrong. This distinction matters because Claude usually doesn't have enough context — whether that department had an unusual transaction this week, say — to judge whether an anomaly is actually an error. Anomaly detection is responsible for finding it; judgment goes to someone with the context to make it. What happens with an anomaly afterward is a separate matter — once detection is done, the next step is usually judging whether the anomaly would affect a core conclusion, deciding whether it needs to go through an Escalation Path.

This is needed because attention naturally can't stay evenly distributed when a person looks through a large batch of data — most items are normal, only a handful have a problem, and the eye easily grows fatigued after scanning past the first dozen-odd normal entries, missing exactly the few that genuinely hide an issue. This effect shows up especially clearly after a batch task finishes, since batch results are usually large in volume, a person isn't likely to examine every item closely, and a quick skim is exactly the mode most prone to missing an outlier — because outliers tend to hide precisely among a pile of data that looks mostly the same. Anomaly Detection exists to hand the work that requires patience and systematic comparison — finding what's different — over to Claude, which doesn't fatigue and can compare an entire batch at once, freeing a person's attention for the part that genuinely needs judgment, once the anomaly has already been flagged.

In practice this works at two levels. The first is defining 'normal range': explicitly tell Claude what counts as normal, such as 'differs from the past four weeks' average by more than a set percentage' — this range needs to be defined based on the task's nature, not left as a vague 'find anomalies' for Claude to guess a standard for. The second is specifying Output Format: every flagged anomaly needs to carry the original value, its gap from normal range, and a possible direction for the cause — duplicate counting, a single large event, a change in calculation logic, say. These cause directions aren't final conclusions; they're a starting point for whoever judges next, so they don't have to guess from scratch. The quality of Anomaly Detection's output depends heavily on how specifically 'normal range' was defined — too loose, and genuinely worth-flagging items get missed; too strict, and a pile of normal natural fluctuation gets flagged too, burying the next person in false alarms.

For you, the real value of Anomaly Detection is turning 'is there a problem in this batch of data' — a question that used to require someone browsing item by item to answer — into work Claude can do systematically, without missing something because it grew tired. This approach fits especially well when the volume is large and normal items dominate the vast majority — the more that's true, the easier it is for manual review to lose patience, and the more anomaly detection's benefit shows. Worth watching: what anomaly detection flags isn't the same as a confirmed error. Treating its output as a conclusion directly — automatically correcting a number just because it got flagged as anomalous, say — conflates the locating stage with the solving stage. The right approach is that once detection finishes, a judgment step still has to decide what to do with the anomaly, usually going through an Escalation Path to reach someone with the capability to confirm it, rather than drawing the conclusion on their behalf.