When false positives exceed 30%, add guard clauses…

When This Fires

• After one-week trigger logging (Classify trigger firings as true/false positives for one…) reveals a false-positive rate above 30%
• When you notice yourself routinely dismissing a trigger because "not now" — that's false-positive data
• When a trigger fires in predictable inappropriate contexts — those contexts are your guard clause candidates
• During trigger calibration when increasing sensitivity (more firings) but needing to maintain precision

Common Failure Mode

Adding too many guard clauses, turning a simple trigger into a multi-step decision process: "When the alarm goes off AND I'm at home AND it's not raining AND I'm not tired AND I don't have a meeting in 30 minutes... go for a run." Each guard clause is a deliberation point that erodes the automaticity the trigger was designed to provide. One or two guard clauses filter false positives; five guard clauses recreate the deliberation the agent was supposed to eliminate.

The Protocol

(1) After logging trigger firings for one week (Classify trigger firings as true/false positives for one…), calculate the false-positive rate. (2) If >30% → identify the most common false-positive context. What single condition would have filtered it? (3) Add that condition as a guard clause: "When [trigger] fires AND [guard clause passes] → execute action." (4) Run for another week. Reclassify firings. If FP rate is now <30% → stop. If still >30% → add one more guard clause for the next most common false-positive context. (5) Never exceed 2-3 guard clauses. If you need more, the trigger itself is wrong — redesign the trigger rather than adding more filters. (6) Scale guard clauses to consequence cost (Scale guard clause complexity to false-positive cost…): a meditation prompt needs zero guards; a "send that difficult email" agent needs a context check.