Unexpected Refusal Diagnosis Prompt

This prompt is designed for trust and safety engineers, AI reliability engineers, and compliance reviewers who need to investigate a single production trace where a model unexpectedly refused a valid user request. The core job-to-be-done is not to rewrite your organization's safety policies, but to isolate the precise trigger: a system prompt rule, a safety classifier activation, an input misclassification, or a policy boundary decision. Use this prompt when a user reports a false-positive refusal, an audit flags an over-block, or a monitoring dashboard shows a refusal-rate spike that requires immediate diagnosis. The required context is a complete production trace containing the user input, the full system prompt, any safety classifier scores, and the final model output or refusal message.

This prompt works by reconstructing the decision path that led to the refusal. It requires you to provide the raw trace data in the [TRACE_DATA] placeholder, which should include the user's original request, the active system prompt, any intermediate safety or policy evaluations, and the final refusal output. The prompt will produce a structured policy decision trace that maps the refusal to its root cause, enabling a concrete decision on whether to adjust the system prompt, tune a classifier threshold, or escalate to a formal policy review. Do not use this prompt for aggregate refusal trend analysis across thousands of sessions or for designing new safety policies from scratch—it is a surgical diagnostic tool for a single incident.

Before running this prompt, ensure you have the complete trace and not just the final user-facing refusal message. A refusal can originate from multiple layers: an explicit rule in the system prompt, a separate safety classifier model, a keyword blocklist, or a misinterpretation of the user's intent. The output will help you distinguish between a correct policy enforcement and a false positive. After diagnosis, the next step is to apply the finding: update the system prompt, adjust a classifier threshold, add the input to an allowlist, or escalate to a policy team if the refusal was correct but the policy itself needs revision. Avoid the temptation to immediately rewrite all safety rules based on a single trace; use this diagnosis as one data point in a broader review cycle.

This prompt template is the core diagnostic instrument for investigating an unexpected refusal event. It is designed to be pasted directly into your trace analysis tool, LLM interface, or an internal review harness. The template forces a structured, evidence-based analysis by requiring the model to isolate the refusal trigger, cite the specific policy or instruction that caused it, and recommend a corrective action. Before running, you must replace every square-bracket placeholder with actual trace data extracted from your observability platform. The prompt does not speculate; it works only with the evidence you provide.

textCopy
You are a trust and safety trace auditor. Your task is to diagnose a single production trace where the model refused a request that should have been allowed. You must identify the exact refusal trigger, cite the governing policy or instruction, and recommend a corrective action. Do not speculate beyond the provided trace data.

## INPUT DATA

### SYSTEM PROMPT
[SYSTEM_PROMPT]

### SAFETY AND POLICY INSTRUCTIONS
[SAFETY_POLICY_INSTRUCTIONS]

### USER INPUT
[USER_INPUT]

### RAW MODEL OUTPUT
[MODEL_OUTPUT]

### SAFETY FILTER LOG
[SAFETY_FILTER_LOG]

### INPUT CLASSIFICATION RESULT
[INPUT_CLASSIFICATION]

### TOOL-CALL LOG (IF ANY)
[TOOL_CALL_LOG]

## OUTPUT SCHEMA

Produce a JSON object with the following structure:

{
  "refusal_detected": true,
  "refusal_trigger": {
    "source": "system_prompt | safety_filter | policy_instruction | input_classification | model_self_censorship | unknown",
    "evidence": "Exact quote or log entry that triggered the refusal.",
    "policy_rule_cited": "The specific rule, instruction, or filter category that was activated."
  },
  "legitimacy_assessment": {
    "request_was_legitimate": true,
    "justification": "Explain why the request should have been allowed, referencing the system prompt's scope and the absence of policy violations."
  },
  "root_cause_analysis": "A concise explanation of the causal chain from input to refusal.",
  "recommended_action": {
    "immediate_fix": "e.g., update safety filter rule, rewrite system prompt clause, adjust classification threshold",
    "target_component": "system_prompt | safety_filter | policy_instructions | input_classifier",
    "revised_instruction_suggestion": "A draft of the corrected instruction or rule."
  },
  "confidence_score": 0.95
}

## CONSTRAINTS
- Base your analysis ONLY on the provided trace data. Do not invent or assume missing information.
- If the evidence is ambiguous, set the confidence score accordingly and explain the ambiguity.
- The `revised_instruction_suggestion` must be a concrete, actionable change.

To adapt this template, start by extracting the required fields from your production trace. The [SYSTEM_PROMPT] and [SAFETY_POLICY_INSTRUCTIONS] are often found in the request metadata or your prompt management system. The [SAFETY_FILTER_LOG] and [INPUT_CLASSIFICATION] typically come from your model gateway or safety stack logs. If your system does not generate a specific field, replace it with 'NOT AVAILABLE' to signal the gap to the model. After pasting the populated prompt, validate the output by checking that the evidence field contains an exact string match from your input data. If the model's confidence score is below 0.85, treat the diagnosis as inconclusive and escalate for human review. This prompt is a diagnostic tool, not an automated decision-maker; always verify its output against your own policy intent before implementing the recommended action.

This prompt is designed to be the first step in a structured triage process, not a standalone report. When a trust and safety engineer flags a trace for review, the application layer should fetch the full trace payload—including the system prompt, user input, safety filter metadata, and any policy evaluation logs—and inject them into the [TRACE_JSON] placeholder. The prompt's output is a structured policy decision trace, which your harness should validate before it reaches a human reviewer or an automated escalation queue.

The implementation harness must enforce three validation gates. First, validate that the output JSON strictly conforms to the expected schema: the refusal_trigger field must be one of the enumerated categories (safety_filter, system_prompt_policy, input_classifier, tool_policy, unknown), and the evidence array must contain at least one trace span ID that can be resolved back to the raw trace data. Second, implement a grounding check: for each evidence span ID, verify that the referenced span exists in the original trace and that its content supports the cited trigger. If the model hallucinates a span ID or misinterprets a policy rule, flag the trace for human review and log the discrepancy. Third, route the validated output based on the refusal_trigger field: safety_filter activations go to the safety engineering queue, system_prompt_policy refusals go to the prompt architecture team, and unknown triggers are escalated with high priority for manual investigation.

For model selection, prefer a model with strong instruction-following and JSON-mode reliability, such as gpt-4o or claude-3-5-sonnet, because the task requires precise extraction over creative generation. Run the prompt with temperature=0 and enable structured output mode if your provider supports it. Log every invocation—including the raw trace input, the model's structured output, and the validation results—to an audit table so that refusal patterns can be aggregated across sessions. Do not use this prompt to automatically override a refusal decision; its purpose is diagnosis and routing, not policy enforcement. The final determination of whether a refusal was correct must remain with a human reviewer who has access to the full trace, the prompt's output, and the validation flags your harness produced.