One Policy, Many Signals

policy config

Part of: Guardrails & Moderation Filter

You now have three independent signals: a blocklist hit, a classifier's category flags, and an injection phrase match. A working guardrails layer has to turn all three into one decision, and hardcoding that as a pile of if statements is exactly the kind of thing that rots. The fix is a policy config : a small, explicit table that maps each category to an action, kept separate from your logic. The config, not the code, holds the rules Changing what happens to harassment from "flag" to "block" is now a one-line config edit, not a code review of scattered conditionals. That matters because these thresholds get tuned constantly as a product learns from real traffic, and a config anyone can read (and a non-engineer can propose changes to) is worth the small extra structure. Combining signals with priority Not every triggered category deserves the same response, so you need a priority order to pick a single overall action when several categories fire at once. block always outranks flag, which always outranks allow: Fail safe on the unknown The policy.get(cat, default) line is the most important line in this lesson. A classifier can return a category name your policy table has never seen:

Challenge: Apply the Policy