A community book-cart helper’s problem is toxic language in answers, not missing catalog facts. Which control matches that responsible-AI feature?

Toxic language in a community book-cart helper is a content-safety failure, not a retrieval gap. A safety or content-policy control—guardrails, moderation filters, or deny-lists tied to generation—is the control that identifies and stops harmful phrasing before it reaches patrons. That maps directly to responsible-AI feature identification: match the harm class (toxicity) to the control class (policy enforcement), then verify the control fires on representative toxic prompts.

A new knowledge base fails the concept because knowledge bases supply facts and citations; they do not classify or block abusive language. Missing catalog facts and toxic wording are different failure modes, so swapping in more documents leaves the harm path open. From-scratch pre-training fails because rebuilding weights from a crawl is a costly capability project, not a deployment-time safety layer, and a weekend crawl does not encode a toxicity policy by itself. Prompt caching fails because a reused static prefix only reduces latency and cost for repeated context; it is not a toxicity classifier and cannot stop novel harmful completions.

Exam caveat: safety filters reduce exposure but are imperfect—adversarial phrasing and domain slang can slip through—so they complement, rather than replace, human review for high-visibility answers. Operational check: before go-live, run a fixed suite of toxic, borderline, and clean book-cart prompts through the helper with the policy control enabled and disabled, confirm toxic cases are blocked or rewritten, clean catalog answers still succeed, and log false-positive rates so librarians can tune thresholds without silently dropping legitimate titles.