Refusal Reason Code Assignment Prompt

This prompt is for safety, policy, and platform engineering teams who need to assign a structured, auditable reason code every time an AI system refuses a user request. The job-to-be-done is not just to refuse, but to produce a machine-readable code from a controlled codebook that downstream systems—such as safety dashboards, compliance auditors, or routing logic—can consume without manual interpretation. The ideal user is an engineer or policy operator integrating this prompt into a safety harness where every refusal must be classified for monitoring, trend analysis, and policy refinement.

Use this prompt when you have a predefined refusal codebook (e.g., ILLEGAL_CONTENT, HARMFUL_INSTRUCTION, OUT_OF_SCOPE, PII_REQUEST) and you need the model to map its own refusal decision to exactly one code, plus a brief, grounded justification. The prompt expects the original user request, the model's refusal response, and the full codebook as input. It is designed for post-hoc classification—running after a refusal has occurred—rather than for making the refusal decision itself. Do not use this prompt to decide whether to refuse; use it to label refusals that have already happened.

This prompt is not a replacement for a safety classifier or a real-time policy engine. It is inappropriate for low-latency, user-facing refusal decisions where a separate classifier should gate the response. It also should not be used when the refusal reason is obvious from the response text alone and no downstream system consumes structured codes. If your codebook changes frequently, you must version the codebook in the prompt and track which version produced each classification. Before deploying, build an eval set that includes borderline cases—requests that could reasonably map to multiple codes—and measure inter-rater agreement between the model and your policy team. The next step is to copy the prompt template, populate your codebook, and wire the output into your logging and alerting infrastructure.

This template assigns a refusal reason code when a model declines a user request. It forces the model to select from a predefined codebook, provide a concise justification, and cite the specific policy clause that triggered the refusal. The template is designed to be wired into a safety layer that sits between user input and the primary model response, ensuring consistent, auditable refusal decisions across your application. Use it when you need structured refusal logging for compliance, safety monitoring, or policy enforcement dashboards.

textCopy
You are a safety classifier. Your job is to determine whether a user request should be refused based on the provided safety policy, and if so, assign the correct refusal reason code.

## INPUT
User Request: [USER_REQUEST]
Conversation History (last 3 turns): [CONVERSATION_HISTORY]

## SAFETY POLICY
[SAFETY_POLICY_DOCUMENT]

## REFUSAL REASON CODEBOOK
You MUST select exactly one code from this list. Do not invent codes.

[REFUSAL_CODEBOOK]

## OUTPUT SCHEMA
Return a valid JSON object with these fields:
- "should_refuse": boolean (true if the request violates policy, false otherwise)
- "refusal_code": string or null (exact code from the codebook if should_refuse is true, null otherwise)
- "policy_clause": string or null (the specific clause ID or section from the safety policy that applies)
- "justification": string or null (one-sentence explanation of why the code applies, citing the policy)
- "safe_alternative": string or null (optional suggestion for a permissible way to address the user's underlying need, if one exists)

## CONSTRAINTS
1. If should_refuse is false, refusal_code, policy_clause, justification, and safe_alternative MUST be null.
2. If should_refuse is true, refusal_code, policy_clause, and justification are REQUIRED. safe_alternative is OPTIONAL.
3. The refusal_code MUST be an exact string match from the codebook. No variations, no synonyms.
4. The justification MUST reference a specific policy clause, not a vague paraphrase.
5. Do NOT refuse requests that fall outside the explicit policy boundaries. Over-refusal is a failure mode.
6. If the request is ambiguous, err on the side of NOT refusing, but flag it with a note in justification.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL: low | medium | high]

If RISK_LEVEL is "high", you MUST include a second field "requires_human_review": true in the output and escalate.

To adapt this template, replace each square-bracket placeholder with your operational data. The [REFUSAL_CODEBOOK] should be a flat list of codes like VIOLENCE, HATE_SPEECH, SELF_HARM, ILLEGAL_ACTIVITY, SEXUAL_CONTENT_MINORS, PRIVACY_VIOLATION, PROMPT_INJECTION, OUT_OF_SCOPE. The [SAFETY_POLICY_DOCUMENT] should contain the actual policy text with clause identifiers. The [FEW_SHOT_EXAMPLES] placeholder is critical: include at least three examples covering a clear refusal, a clear non-refusal, and a boundary case where the model correctly chooses not to refuse. Without these examples, models tend to over-refuse on ambiguous inputs. The [RISK_LEVEL] parameter controls whether the output includes a human review flag—set it to high for regulated domains like healthcare or child safety, where automated refusal decisions must be audited before enforcement.

Before deploying, validate that the model never emits codes outside the codebook. A common failure mode is the model inventing a plausible-sounding code like HARASSMENT when the codebook only contains BULLYING_AND_HARASSMENT. Use an exact string match validator in your application layer and reject any output with an unknown code. Log these rejections as REFUSAL_CODE_VALIDATION_ERROR so you can tune the prompt or expand the codebook. For high-risk deployments, route all refusals with requires_human_review: true to a review queue before the refusal is surfaced to the user.

The Refusal Reason Code Assignment prompt is designed to sit inside a safety evaluation pipeline, not as a standalone chat interaction. When a primary model generates a response that includes a refusal, the refusal text is extracted and passed to this prompt along with the original user request and the active safety policy codebook. The prompt returns a structured refusal reason code, a confidence score, and a justification. This output should be consumed by a downstream routing or logging system, not displayed directly to end users.

Validation and retry logic is critical because an incorrect or missing code breaks downstream safety dashboards and audit trails. Implement a post-generation validator that checks: (1) the returned code exists in the active codebook, (2) the confidence score is a float between 0.0 and 1.0, (3) the justification field is non-empty and references specific policy clauses, and (4) the output parses as valid JSON matching the expected schema. If validation fails, retry once with the validation error message appended to the prompt context. If the retry also fails, log the failure and route to a human review queue rather than silently assigning a default code. For high-risk domains, always require human confirmation when the model assigns codes related to self-harm, child safety, or regulated content categories.

Model selection matters for consistency. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, with the response format set to JSON mode or structured outputs. Avoid smaller models that may hallucinate codes or skip the justification field. Logging should capture the full input context (user request, refusal text, policy codebook version), the assigned code and confidence, the validator result, and any retry attempts. This trace data is essential for auditing refusal patterns, detecting over-refusal or under-refusal drift, and updating the codebook over time. Wire these logs into your existing observability stack with alerts for sudden spikes in specific refusal codes or validator failure rates.

Integration pattern: deploy this prompt as a gated step after the primary model response but before the response is returned to the user or logged as final. If the primary response contains a refusal (detected via keyword matching, a separate refusal classifier, or a dedicated refusal token), extract the refusal span and call this prompt. Use the returned code to populate safety metadata fields in your response envelope. If the code indicates a policy violation, block the response and return a safe fallback. If the code indicates a benign refusal (e.g., capability boundary), you may still return the refusal to the user but with the code attached for analytics. Never expose the raw justification field to end users; it is an internal audit artifact.

What to avoid: do not use this prompt to decide whether a refusal should have occurred—that is a separate policy evaluation step. This prompt only classifies the refusal that already happened. Do not skip validation in production; an unvalidated code corrupts your safety metrics. Do not treat all refusal codes as equally sensitive; build routing logic that escalates high-severity codes for human review while allowing low-severity codes to flow through with automated logging. Finally, version your codebook and tie each prompt call to a specific codebook version so that historical refusal data remains interpretable when the codebook evolves.