Refusal with Educational Resource Redirection Prompt Template

This prompt template is designed for trust-and-safety engineers and product teams who need to transform a dead-end refusal into a constructive, educational interaction. The core job-to-be-done is to refuse a harmful or disallowed user request while simultaneously redirecting the user to authoritative, vetted resources where they can learn more about the topic safely. This pattern is ideal when your platform maintains a curated library of educational content, official policy documentation, or verified support channels, and you want refusals to serve a harm-reduction function by guiding users toward accurate information instead of leaving them to search for it independently, which could lead them to more dangerous material.

You should use this prompt when the refused request falls into a category where user education is a viable and safe alternative. For example, if a user asks for instructions on a dangerous activity, the refusal can link to a public health resource explaining the risks. If a user requests prohibited content, the refusal can point to your platform's content policy and an educational article about online safety. The key prerequisite is that your team has already vetted and approved the resource links for the relevant refusal categories. Do not use this prompt in regulated domains such as medicine, law, or finance where any engagement, even a refusal with a resource link, could be construed as creating a duty of care or liability. For those cases, use the Regulated Domain Refusal with Liability Disclaimer template. Similarly, do not use this prompt for detected jailbreak or prompt injection attempts where the safest response is a neutral non-engagement that reveals nothing about your detection mechanisms; use the Jailbreak Attempt Refusal and Logging template instead.

Before implementing this prompt, ensure your team has mapped refusal categories to specific, live resource URLs and that a process exists to periodically audit those links for availability and continued relevance. A broken or irrelevant link in a refusal message undermines user trust and can generate more support tickets than a simple refusal. Wire this prompt into your application with a validation step that checks the generated response contains at least one valid URL from your approved resource list and that the refusal language does not accidentally endorse or describe the harmful request in detail. Start with a narrow set of refusal categories where educational redirection has a clear user benefit, measure the impact on support ticket volume and user follow-through rates, and expand the category coverage based on data.

This template is designed to be wired directly into your safety classifier's output. When a user request is flagged as disallowed, this prompt generates a refusal that does more than say 'no'. It explains the refusal, cites the relevant policy, and provides a concrete, safe next step by linking to an educational resource. The goal is to maintain user trust and reduce support tickets by turning a dead-end into a learning opportunity.

textCopy
You are a safety response system. Your task is to refuse a user request that violates a safety policy and redirect the user to an authoritative educational or support resource.

USER REQUEST:
[USER_INPUT]

VIOLATED POLICY:
[POLICY_NAME]

POLICY RATIONALE:
[POLICY_RATIONALE]

REDIRECT RESOURCE:
Title: [RESOURCE_TITLE]
URL: [RESOURCE_URL]
Description: [RESOURCE_DESCRIPTION]

REFUSAL TONE: [TONE]

OUTPUT_SCHEMA:
{
  "refusal_message": "string (the full text shown to the user)",
  "policy_cited": "string",
  "resource_provided": {
    "title": "string",
    "url": "string"
  }
}

INSTRUCTIONS:
1. Acknowledge the user's request without repeating or amplifying harmful content.
2. Clearly state that you cannot fulfill the request.
3. Explain the refusal by referencing the [POLICY_NAME] and [POLICY_RATIONALE] in plain, honest language.
4. Introduce the [RESOURCE_TITLE] as a helpful alternative, explaining what the user can learn there.
5. Provide the full [RESOURCE_URL].
6. Adhere strictly to the [TONE] variable (e.g., 'empathetic', 'professional', 'direct').
7. Do not apologize for the policy itself.
8. Do not suggest workarounds or alternative ways to achieve the harmful goal.
9. Output only the valid JSON object matching the OUTPUT_SCHEMA.

To adapt this template, replace the square-bracket placeholders with values from your upstream safety classifier and resource database. The [TONE] variable should be controlled by your product's configuration, allowing A/B testing of refusal styles. Before deploying, validate that the generated refusal_message does not inadvertently leak the [POLICY_RATIONALE] in a way that educates malicious users on how to bypass the policy. Run evals to ensure the [RESOURCE_URL] is valid, the resource is genuinely authoritative, and the refusal correctly maps to the [POLICY_NAME] that was violated.

This prompt is designed to be called after an upstream safety classifier or policy engine has already determined that a user request must be refused. It should not be the sole decision point for refusal. The application layer must first classify the request, map it to a policy category, and select the appropriate educational resource URL before invoking this prompt. The prompt's job is to generate a user-facing message that refuses the request while directing the user to an authoritative resource relevant to the refused category. This separation of concerns—classification and resource selection in application code, message generation in the prompt—keeps policy decisions auditable and prevents the model from hallucinating resource URLs or policy boundaries.

Integration flow: 1) User input arrives. 2) Safety classifier returns a violation category and confidence score. 3) If confidence exceeds the refusal threshold, the application looks up the category in a resource mapping table to retrieve the correct URL, resource title, and policy reference. 4) The prompt is assembled with the original request, the violation category, the resource metadata, and the configured tone parameters. 5) The model generates the refusal message. 6) The output is validated before being returned to the user. Validation checks must include: URL presence and format (the resource link must be non-empty and match an allowlisted domain pattern), policy reference presence, absence of the original harmful request echoed in a way that could be screenshotted and shared, and tone consistency with the configured parameters. If validation fails, fall back to a static refusal template rather than retrying with the model—retry loops on refusal generation can produce inconsistent policy messaging.

Model choice and latency: This prompt works reliably with fast, cost-effective models because the generation task is constrained and templated. There is no need for a large frontier model. Consider using a smaller model with strict temperature settings near zero to maximize output consistency. Logging requirements: Log the violation category, resource URL, model version, prompt template version, and a hash of the generated refusal text. Do not log the full user request if it contains harmful content that could expose log reviewers to abuse material—store a content hash instead. Feedback loop: Track click-through rates on the educational resource link. Low click-through rates per category may indicate that the resource is not perceived as relevant or trustworthy. Periodically review refusal logs by category to identify resource staleness and update the mapping table. This harness turns a static refusal into a measurable safety intervention.