Troubleshooting Retrospective: Assigning a "Handling Budget" to False Positives Saved the Detection Team Two Person-Months

Last month, we deployed a content anomaly detection system for the business side. Within the first week, we ran into a familiar problem: the model was too "sensitive," flagging a high volume of anomalies with high confidence scores. The manual review queue piled up with over 3,000 items in just three days. The business team’s conclusion was blunt: "We can’t review this many false positives; stop using it for now."

The root cause wasn’t model accuracy—offline evaluations showed the precision met requirements—but rather that we hadn’t defined a **handling budget** for false positives. Without a budget, false positives expand indefinitely, overwhelming manual review capacity. Ultimately, the entire pipeline gets scrapped, not just the false positives themselves.

Step 1: Distinguish Between "Business-Unacceptable False Positives" and "Technically Automatable False Positives"

We analyzed two weeks of manual review records, tagging each false positive to determine: What is the actual cost of reviewing and discarding this item? Which items should never have reached human reviewers in the first place?

The results showed that about 30% of false positives fell into the same category: they triggered on routine batch operations that our system had already logged the day before. These were "documented known patterns." Sending them for manual review was purely wasteful; they should have been automatically handled and logged via configuration.

This step didn’t save money on the model; it saved money on labor. Model precision remained unchanged, but the daily volume entering the manual review queue dropped from over 3,000 items (accumulated over three days) to just over 1,000.

Step 2: Hardcode the "Daily Budget" in the Scheduling Layer, Instead of Relying on Daily Human Guesswork

We established a hard rule for the review queue: **Manual reviewers will process a maximum of 200 items per day. Items exceeding this limit are neither discarded nor escalated as alarming alerts to scare the team. Instead, they are downgraded to "Observation Level" and processed in parallel by an automated decision-making channel.**

The key isn’t the number "200," but the fact that it is "written into configuration + triggers over-budget alerts." On days when the budget is exceeded, someone must review the alert and decide whether to temporarily increase the limit. If no one reviews the alert, it means the budget is set incorrectly or upstream conditions have changed. Once a budget is integrated into the scheduling layer, there must be designated personnel monitoring the alerts—setting a number without configuring alerts is equivalent to having no configuration at all.

Step 3: Deploy the Observation-Level Channel Independently, Otherwise the Secondary Channel Is Fake During Bursts

Initially, the automated decisions for over-budget items reused cached results from the main detection channel, which was engineeringly convenient. However, one day, upstream batch operations changed their pattern, causing the entire cache to become invalid. The over-budget batch had no budget for manual review, and the automated system couldn’t retrieve results. This caused a backlog that piled up for two to three days, requiring manual queue intervention to clear.

Subsequently, we decoupled the "over-budget automated decision" logic into an independent service: it does not rely on the main channel’s cache, has its own queue and retry limits, and ensures there is at least a fallback mechanism during traffic bursts. After this separation, similar failure incidents dropped to zero.

Metrics After Implementing the Budget

- Review queue length: From 3,200 items/day → Average 610 items/day

- Manual review SLA (from queuing to final decision): 46 hours → 8 hours

- Automated processing rate: 22% → 68%

- Over-budget alerts: Triggered once in two weeks. The cause was an upstream batch job starting 40 minutes early; we lowered the daily budget by 50 items instead of forcing the system to cope with the surge.

A One-Liner for On-Call Engineers

Accuracy reports won’t tell you "who is looking at these results." A budget doesn’t restrict the model; it restricts human effort. First, hardcode the handling capacity, then determine how high the model’s sensitivity can go. If you reverse this order, the business side will only see a bunch of nice-looking curves and hear one phrase: "It’s unusable."