A consumer forum's moderation team is configuring content filtering for a Foundry-hosted chat model. They want casual profanity to pass through unfiltered, since their community tolerates it, but they still need hate speech and self-harm content blocked, and they also know a handful of coded slurs specific to their community that the default categories do not reliably catch. (Select TWO.) Which two configuration steps should the team take?
Select all correct answers, then click Submit.
Short Explanation
Picture the filtering system as a set of dials plus an extra list a moderator can hand-write. The team wants one dial, the one for casual swearing, turned down so it stops catching things they are fine with, while the other dials, for hate speech and self-harm, stay right where they are protecting people. That handles the tolerance part. But there is a separate problem: some slang specific to their own community slips past every dial because it was never part of what those categories were trained to recognize. That calls for the handwritten list, a place to add exactly those terms so they get caught regardless of what the automatic categories decide. Turning everything off would solve nothing, since it strips away protection from the very things they want blocked. And hoping the model just knows better on its own ignores that this kind of fine control exists precisely so teams do not have to leave it to chance.
Full Explanation
The correct answers are C and D. Adjusting the severity threshold on the category that governs profanity lets that specific kind of language through while the hate speech and self-harm categories stay at their protective settings, which matches the team's goal of tolerating casual swearing without loosening protection against more harmful content. Adding the coded community-specific terms to a custom blocklist directly addresses the gap the team identified, since default categories are trained on broad patterns and will not reliably catch slang unique to one community; a blocklist lets the team filter those exact terms regardless of what the general categories detect. Option A is incorrect because disabling filtering entirely removes protection against hate speech and self-harm as well, which contradicts the requirement to keep those blocked, and after-the-fact manual review does not prevent harmful content from reaching users first. Option B is incorrect because the model's training behavior is not something the moderation team can adjust through configuration, and depending on it alone ignores the deliberate tooling, threshold controls and blocklists, that Foundry provides specifically for this kind of fine-grained control.