Educational Refusal Prompt with Learning Resource Redirection

This prompt is designed for edtech platforms, information services, and learning assistants that must refuse a user request while preserving educational value. Instead of a flat denial, the model explains the pedagogical or policy reason behind the refusal and redirects the user to legitimate learning resources. The primary job-to-be-done is transforming a potentially negative user experience into a constructive teaching moment. The ideal user is a product team that has already defined a safety policy and curated a set of redirectable learning resources, such as textbook chapters, verified articles, or interactive exercises, and now needs a reliable, on-brand way to say no without shutting down the user's learning journey.

You should use this prompt when your application needs to refuse requests for direct answers, generated essays, or disallowed content, but your product principles demand guiding the user toward understanding the underlying concept. This is common in homework help platforms that prohibit doing the work for the student, or in information services that cannot provide medical, legal, or financial advice but can point to authoritative sources. The prompt assumes you have a pre-defined [SAFETY_POLICY] that clearly states what is disallowed and a [RESOURCE_LIST] of approved, high-quality learning materials. It works best when the refusal reason is genuinely educational (e.g., 'I can't write your essay, but I can help you outline your thesis') rather than purely legalistic.

Do not use this prompt when the user's request is malicious, abusive, or falls into a category requiring a firm, non-negotiable refusal with no alternative path. In those cases, a direct refusal prompt from the safety policy pillar is more appropriate. Also, avoid this prompt if you lack a curated resource base; redirecting users to low-quality or unverified materials damages trust and creates liability. Before deploying, ensure your evaluation suite checks for both policy compliance and educational value, and implement a human review step for any refusal that the model flags as ambiguous or high-risk.

This template is designed to be pasted directly into your system prompt or safety guard layer. It instructs the model to detect when a user request falls outside the allowed educational scope—such as requests for completing graded assignments, writing entire essays for submission, or generating content that violates academic integrity policies—and to respond with a structured refusal that explains the policy boundary and offers a constructive alternative. The prompt is parameterized with square-bracket placeholders that you must replace with your application's specific policies, resource URLs, and output requirements before deployment.

textCopy
You are an educational AI assistant. Your primary goal is to help users learn, not to complete their work for them.

When a user request asks you to perform a task that violates the educational policy defined below, you must refuse the request. Your refusal must follow the [REFUSAL_SCHEMA] structure exactly.

## POLICY
[EDUCATIONAL_POLICY]

## ALLOWED RESOURCES
[LEARNING_RESOURCES]

## REFUSAL SCHEMA
When refusing, output a JSON object with these fields:
- "decision": "refused"
- "policy_violated": A short identifier from the policy list.
- "explanation": A 2-3 sentence explanation of why the request cannot be fulfilled, written in an educational and non-judgmental tone.
- "learning_alternative": A specific suggestion for how the user can learn the material instead, referencing one or more items from [LEARNING_RESOURCES] where applicable.
- "clarifying_question": An optional question that helps the user reframe their request into an allowed learning activity.

## CONSTRAINTS
- Never imply the user is cheating or acting in bad faith.
- Never generate the disallowed content even as an example of what not to do.
- If the request is ambiguous, ask one clarifying question before refusing.
- If the request is clearly allowed, respond helpfully without invoking this policy.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## CURRENT REQUEST
User: [USER_INPUT]

To adapt this template, start by replacing [EDUCATIONAL_POLICY] with a clear, enumerated list of disallowed request categories (e.g., 'writing full essays for submission', 'completing graded quizzes', 'generating content the user will misrepresent as their own work'). Replace [LEARNING_RESOURCES] with a list of approved resources, such as links to your platform's tutorials, documentation, or external references like Khan Academy or official textbook sites. The [FEW_SHOT_EXAMPLES] placeholder should be populated with 3–5 example user requests and the corresponding correct JSON refusals, including edge cases where the request is ambiguous. Before shipping, validate that the model's output consistently matches the [REFUSAL_SCHEMA] structure by running a regression suite of known disallowed and allowed requests. If the model's refusal tone drifts toward judgmental or the JSON schema is violated, adjust the constraints or add more examples. For high-stakes academic integrity contexts, route a sample of production refusals to human review to confirm that the educational value of the redirection is genuine and not evasive.

This prompt is designed to sit behind a safety classifier in a request pipeline. Before the model ever sees the user input, a lightweight upstream classifier should determine whether the request falls into a disallowed category. If it does, the classifier routes the request to this educational refusal prompt instead of the main assistant prompt. This separation keeps the refusal logic clean and prevents the main system prompt from needing to handle every policy edge case. The refusal prompt receives the original user query, the triggered policy category, and any relevant learning resource mappings your team has curated.

Wire the prompt into your application as a dedicated refusal handler with the following components: Input validation—verify that [USER_QUERY] is non-empty and that [POLICY_CATEGORY] matches one of your defined categories before calling the model. Resource lookup—maintain a mapping of policy categories to approved learning resources (URLs, course IDs, article references) in your application layer, and pass only the relevant subset into [LEARNING_RESOURCES] to keep the prompt focused. Output validation—parse the model response to confirm it contains a refusal statement, an educational explanation, and at least one resource reference. If the output is missing any of these components, retry once with a stronger constraint instruction. Logging—capture the policy category, user query, refusal output, and whether resources were included, for safety audit trails and over-refusal analysis. Human review trigger—if the model produces a refusal that appears to accept the disallowed request or provides resources that could enable harm, flag for human review before the response reaches the user.

Model choice matters here. Use a model with strong instruction-following and low refusal-creep for this task—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are reasonable defaults. Avoid smaller models that may conflate educational explanation with compliance or produce inconsistent refusal structures. Set temperature low (0.0–0.2) to keep refusal language stable across calls. Do not use this prompt as a standalone safety layer; it assumes an upstream classifier has already made the routing decision. If your system lacks a classifier, pair this prompt with a classification step first. The educational refusal prompt is not a detection mechanism—it is a response generation mechanism for already-identified policy violations.