Safety Filter Activation Root-Cause Analysis Prompt

This prompt is a single-trace diagnostic tool built for safety engineers and AI SREs who need to isolate the exact trigger that caused a safety filter to activate on a specific production request. The job-to-be-done is forensic root-cause classification: you have a raw trace containing the user input, system prompt, and any intermediate tool calls or retrieval context, and you need to know why the filter fired. The prompt produces a structured classification (e.g., keyword match, semantic violation, instruction conflict) with supporting evidence extracted from the trace, a confidence score, and a checklist to rule out false positives. It is designed for deep, individual investigation, not for bulk categorization or stakeholder reporting.

Use this prompt when a refusal event requires precise diagnosis before you can decide on a remediation action—such as tuning a policy definition, adjusting a system prompt, or filing a bug against a safety classifier. The ideal user has access to the full trace payload and understands the safety policy taxonomy in use. The prompt assumes the trace is already isolated; it does not search logs or aggregate events. It is most effective when the activation signal is ambiguous, such as when a legitimate user request is blocked or when multiple safety mechanisms could be responsible. The required inputs are the raw trace, the applicable safety policy definitions, and the expected output schema for the root-cause classification.

Do not use this prompt for bulk categorization of refusal events across thousands of traces—batch processing requires a different, lower-fidelity prompt optimized for throughput and taxonomy normalization. Do not use it to generate stakeholder summaries or trend reports; it produces technical diagnostic output meant for engineers who will act on the findings. Avoid using it when the trace data is incomplete or when the safety policy definitions are not available, as the confidence score will degrade and the false-positive checklist becomes unreliable. After running this prompt, the next step is typically to apply a remediation action and then validate the fix using a regression test prompt or a policy boundary decision audit prompt.

This prompt template is designed to be pasted directly into your LLM interface or trace analysis tool. It accepts a structured production trace as input and produces a root-cause classification with supporting evidence. The template is self-contained: it defines the analysis task, the required output schema, and the evaluation criteria. You only need to replace the square-bracket placeholders with data from your production trace before execution.

textCopy
You are a safety filter diagnostic analyst. Your task is to analyze a production trace where a safety filter activated and determine the root cause.

## INPUT
[TRACE_DATA]

## ANALYSIS INSTRUCTIONS
1. Reconstruct the full request context from the trace, including user input, system prompt, retrieved context, and any tool calls.
2. Identify the exact point in the trace where the safety filter activated.
3. Classify the root cause into exactly one of the following categories:
   - KEYWORD_MATCH: A specific word or phrase triggered a static filter.
   - SEMANTIC_VIOLATION: The request's meaning violated a safety policy, even without exact keyword matches.
   - INSTRUCTION_CONFLICT: The system prompt or tool instructions created a conflict that triggered the filter.
   - RETRIEVAL_CONTAMINATION: Retrieved context contained content that triggered the filter.
   - USER_ADVERSARIAL_INPUT: The user employed prompt injection, encoding tricks, or role-playing to bypass filters.
   - FALSE_POSITIVE: The filter activated on benign content that does not violate any policy.
   - UNKNOWN: Insufficient evidence in the trace to determine the cause.
4. Extract the specific evidence from the trace that supports your classification.
5. Assign a confidence score from 0.0 to 1.0 reflecting how certain you are in the classification.
6. Complete the false positive checklist: rule out keyword false matches, semantic misinterpretation, and context contamination before confirming a false positive.

## OUTPUT SCHEMA
Return a valid JSON object with this exact structure:
{
  "root_cause_classification": "KEYWORD_MATCH | SEMANTIC_VIOLATION | INSTRUCTION_CONFLICT | RETRIEVAL_CONTAMINATION | USER_ADVERSARIAL_INPUT | FALSE_POSITIVE | UNKNOWN",
  "confidence_score": 0.0,
  "supporting_evidence": [
    {
      "trace_location": "description of where in the trace the evidence was found",
      "evidence_type": "USER_INPUT | SYSTEM_PROMPT | RETRIEVED_CONTEXT | TOOL_CALL | TOOL_RESPONSE | MODEL_OUTPUT | FILTER_LOG",
      "content_snippet": "the relevant excerpt from the trace",
      "explanation": "why this evidence supports the classification"
    }
  ],
  "false_positive_checklist": {
    "keyword_false_match_ruled_out": true,
    "semantic_misinterpretation_ruled_out": true,
    "context_contamination_ruled_out": true,
    "overall_false_positive_likely": false
  },
  "recommended_action": "REMOVE_KEYWORD | UPDATE_POLICY | FIX_SYSTEM_PROMPT | CLEAN_RETRIEVAL | STRENGTHEN_FILTER | APPEAL_FALSE_POSITIVE | ESCALATE_TO_HUMAN | NO_ACTION"
}

## CONSTRAINTS
- Do not fabricate evidence not present in the trace.
- If the trace is incomplete, set confidence_score below 0.5 and classify as UNKNOWN.
- For any classification other than FALSE_POSITIVE, the false_positive_checklist fields must all be false.
- The recommended_action must be consistent with the root_cause_classification.

To adapt this template, replace [TRACE_DATA] with the full JSON or structured log from your production trace. If your trace format differs, add a brief mapping note before the trace data explaining the field names. For batch analysis, wrap this prompt in a loop that iterates over multiple traces and collects the JSON outputs. Always run the output through a JSON schema validator before ingesting it into your incident response or monitoring pipeline. For high-severity safety incidents, route any classification with confidence_score below 0.7 or root_cause_classification of UNKNOWN to a human reviewer before taking action.

This prompt is designed to be a single step in a larger trace analysis pipeline, not a standalone chat interaction. The primary integration point is a post-processing worker that consumes raw trace events from your observability store (e.g., a log database, a trace analytics platform, or a message queue). When a safety filter activation event is detected by your monitoring system, the worker fetches the full trace payload for that request, hydrates the [TRACE_JSON] placeholder, and sends the completed prompt to a capable LLM for structured analysis.

For production use, the model choice matters. Use a model with strong instruction-following and JSON mode support (e.g., GPT-4o, Claude 3.5 Sonnet). The output schema must be enforced. Configure your API call with response_format: { type: 'json_object' } and provide the expected JSON schema in the API's dedicated schema parameter, not just in the prompt text. After receiving the response, validate the JSON structure against your expected schema. If the confidence_score is below your threshold (e.g., 0.7) or the root_cause_classification is ambiguous, route the trace to a human review queue. Log the full prompt, the model's raw response, and the validation result for auditability. Implement a retry with exponential backoff for malformed JSON, but stop after three attempts and escalate to a human operator.

The prompt's false_positive_checklist output is a critical signal for your pipeline. If any checklist item is flagged as true, automatically suppress any automated enforcement action (e.g., user suspension, content removal) pending human review. Do not use the model's output to automatically block users or delete content without a human-in-the-loop step. Store the structured root-cause analysis alongside the original trace in your data warehouse to enable trend analysis over time. This allows you to build dashboards that track the most common root causes of safety filter activations, informing your next prompt iteration or safety policy update.