Safety Boundary Clarification Prompt

This prompt is designed for safety-sensitive assistants that receive user requests near a defined policy boundary. Instead of issuing a flat refusal or silently blocking the request, the assistant generates a targeted clarification question that probes the user's genuine intent without revealing internal safety classifier logic. The prompt simultaneously offers a safe, in-policy alternative so the user has a productive path forward. Use this when your product must handle ambiguous edge cases around content generation, data access, regulated advice, or platform capabilities where a hard refusal would damage user trust but an unqualified acceptance would violate policy.

The ideal user is an AI engineer or product manager deploying a customer-facing assistant where policy boundaries are not binary. For example, a user asking 'Write a script that scrapes competitor pricing' could be a legitimate business intelligence request or a terms-of-service violation. The prompt helps the assistant ask a targeted question like 'Are you looking for a public API client for market research, or a tool to bypass access controls?' while offering a compliant alternative such as 'I can help you structure a manual competitive analysis template.' This approach preserves user trust and keeps the conversation productive without exposing the internal risk assessment logic.

Do not use this prompt for clearly malicious requests that require immediate refusal with no alternative, or for requests so far outside policy that any clarification would imply the assistant can help with disallowed tasks. If a user asks for instructions to commit fraud, a hard refusal with no alternative is appropriate. If a user asks for medical advice in a non-clinical product, the boundary is clear enough that a standard disclaimer and refusal is sufficient. Reserve this prompt for the gray zone where intent is genuinely ambiguous and a well-designed clarification question can redirect the user to a safe, valuable outcome. Before deploying, define your policy boundary explicitly and test the prompt against both in-policy and out-of-policy examples to ensure the clarification trigger threshold is calibrated correctly.

This prompt template is designed to be inserted into your system prompt or activated as a policy instruction block when a safety classifier detects a request near a policy boundary. Its job is to generate a clarification that probes the user's true intent without exposing the internal workings of your safety classifier, while simultaneously offering a safe, productive alternative. The template uses square-bracket placeholders that you must replace with your specific policies, risk levels, and output constraints before deployment.

textCopy
## SAFETY BOUNDARY CLARIFICATION MODE

You are operating in Safety Boundary Clarification Mode. A user request has been flagged as approaching a policy boundary defined in [POLICY_DOCUMENT]. Your task is not to refuse outright, but to clarify the user's intent and offer a safe alternative path.

### INPUT
User Request: [USER_REQUEST]
Flagged Policy Category: [POLICY_CATEGORY]
Risk Level: [RISK_LEVEL]  # Options: LOW, MEDIUM, HIGH, CRITICAL

### CONSTRAINTS
- Do NOT reveal the specific rule, classifier score, or internal policy language that triggered this mode.
- Do NOT repeat or amplify the potentially harmful content of the original request.
- Do NOT engage in a debate about the policy itself.
- Your response MUST include exactly one clarifying question and one safe alternative.

### OUTPUT FORMAT
Respond with a JSON object matching this exact schema:
{
  "clarification_question": "A single, neutral question that probes the user's underlying, legitimate intent without repeating the disallowed request.",
  "safe_alternative": "A concrete, actionable suggestion for a task you can perform that is adjacent to the user's apparent goal but fully within policy.",
  "assumed_intent": "A brief, neutral description of what you believe the user is trying to accomplish, framed in policy-compliant language."
}

### EXAMPLES
[FEW_SHOT_EXAMPLES]

To adapt this template, start by replacing [POLICY_DOCUMENT] with a concise summary of your relevant policy, such as 'Content Policy: No generation of violent content.' The [FEW_SHOT_EXAMPLES] placeholder is critical for performance; provide 2-3 examples showing a boundary request, a good clarification question, and a strong safe alternative. For high-stakes deployments, the [RISK_LEVEL] should be used to gate the response: for CRITICAL risks, you might override this prompt entirely with a hard refusal. Always route the final output through a validation step that checks for valid JSON and ensures the clarification_question does not contain the original flagged terms. In regulated domains, log the assumed_intent and the final user response for audit and human review.

The Safety Boundary Clarification Prompt is a high-stakes component that sits between a user's request and a downstream action. It must never be treated as a standalone prompt. Instead, it should be embedded in a harness that validates the output structure, enforces policy boundaries, and escalates to human review when the model's confidence or behavior is uncertain. The primary integration point is after a safety classifier has flagged a request as near-boundary, but before any tool execution or definitive response is returned to the user.

The implementation harness requires three mandatory validation layers. First, a structural validator must confirm the output contains the required fields: boundary_category, clarification_question, safe_alternative_offer, and refusal_escalation_flag. Use a JSON schema or Pydantic model to reject malformed responses and trigger a retry. Second, a policy validator must check that the clarification_question does not leak internal safety classifier logic, such as mentioning specific blocked categories, confidence scores, or detection methods. A simple keyword blocklist combined with a secondary LLM-as-judge check can catch leakage. Third, an escalation router must inspect the refusal_escalation_flag. If set to true, the response must be queued for human review rather than returned to the user automatically. For high-risk domains like healthcare or finance, consider requiring human approval for any boundary response, regardless of the flag.

For model choice, prefer models with strong instruction-following and low refusal overgeneralization. Test across at least two model families (e.g., Claude and GPT) to ensure the prompt does not produce false refusals on legitimate requests or fail to clarify on genuine boundary cases. Implement a retry strategy with a maximum of two attempts: if the structural validator fails, re-invoke with the validation error appended to the prompt context. If the policy validator fails, do not retry—escalate immediately. Log every boundary clarification event with the user request, classifier score, model response, validation results, and final routing decision. These logs form the audit trail for safety review and prompt iteration. Do not cache boundary clarification responses, as each request requires fresh evaluation against current policy and context.

Before deploying, build a regression test suite with three categories of test cases: (1) clear policy violations that should trigger refusal with escalation, (2) ambiguous requests that should produce a clarification question and safe alternative, and (3) legitimate requests near the boundary that should pass through without unnecessary friction. Measure false-positive clarification rates on legitimate traffic and false-negative pass-through rates on policy-violating requests. If the false-positive rate exceeds 5% on legitimate requests, tune the upstream safety classifier thresholds rather than modifying this prompt. If the false-negative rate exceeds 1%, tighten the escalation flag criteria and increase human review coverage. Run these evals on every prompt change before release.