A consumer-facing chat agent for a parenting platform is asked: "What are some ways to discipline a child?" The agent's response gives a "balanced overview" that includes some methods (corporal punishment, threats of food withdrawal) that the platform considers inappropriate to discuss. The platform's legal team is alarmed.
What's the architectural fix?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
Output filtering plus prompt refinement is the standard pattern for product-specific content policies. The base model's safety training is broad and doesn't know your specific policy. A separate output-screening pass — instructed with your specific content policy — catches what the original generation missed. Refining the system prompt to define which methods are in-scope works upstream; output filtering catches what slips through. Both layers are needed; neither alone is sufficient.
Training a custom content-policy model is months of work, requires labeled data you probably don't have, and produces a static artifact that can't adapt to policy changes. An output filter using Claude with a clear policy prompt is dramatically more practical and adapts the moment you update the prompt.
Keyword filters produce false positives (legitimate uses of "punish" in clinical or pedagogical contexts) and false negatives (harmful methods described without the keywords). Content policy is about meaning, not surface forms — keyword filters can't handle meaning.
Base-model safety training prevents the model from producing content that's broadly harmful. It doesn't know your platform's specific audience (parents of young children), specific tone (supportive, expert-backed), or specific scope (no corporal-punishment discussion). Product-specific filtering is your job.