False Positive Reduction Analysis Prompt for Escalations

This prompt is designed for trust and safety operations teams who need to analyze batches of escalated items that were adjudicated by human reviewers and found to be non-violations (false positives). The job-to-be-done is systematic queue-quality improvement: you have a labeled dataset of reviewer outcomes and need to identify patterns in the detection logic that cause over-escalation, propose root cause hypotheses, and recommend specific threshold or rule adjustments. The ideal user is an operations analyst, trust and safety engineer, or review queue manager who owns escalation quality metrics and has access to adjudicated case data. Required context includes the original escalation reasons, the human reviewer's final determination and rationale, and any relevant policy definitions or detection rule configurations that were active when the cases were escalated.

Use this prompt when you have a batch of at least 20-50 adjudicated false positive cases and want a structured analysis to reduce future over-escalation without increasing the risk of missed true violations. The prompt expects aggregate batch analysis, not single-case review. It works best when the input data includes consistent fields: case ID, escalation trigger reason, detection confidence score (if available), human reviewer outcome, reviewer notes, and the policy or rule that triggered escalation. You should not use this prompt for real-time violation detection, for analyzing individual cases in isolation, or for cases where the human reviewer outcome is unknown or unlabeled. It is also inappropriate for analyzing true positive escalations or for evaluating human reviewer accuracy—this prompt focuses exclusively on false positive pattern reduction.

Before using this prompt, verify that your dataset is complete and that reviewer outcomes are final. Incomplete or provisional outcomes will produce unreliable pattern analysis. If your review queue handles high-severity content (child safety, self-harm, imminent harm), ensure that any threshold adjustment recommendations from this analysis are reviewed by policy and legal stakeholders before implementation. The prompt produces recommendations, not automated rule changes. After running the analysis, the next step is typically a calibration exercise where proposed threshold adjustments are tested against a holdout set of true positive cases to verify that recall does not degrade below acceptable risk thresholds.

This prompt template is designed to be dropped into a batch analysis workflow. It expects a structured dataset of escalation records that have already been adjudicated by human reviewers, with each record containing the original AI output, the guardrail that was triggered, the escalation reason, and the final human determination (true positive or false positive). The prompt instructs the model to perform a root cause analysis across the batch, identify systemic patterns, and propose concrete threshold or policy adjustments. Adapt the placeholders to match your internal data schema, policy names, and risk tolerance before use.

codeCopy
You are a trust and safety operations analyst reviewing a batch of false positive escalations. Your goal is to identify systemic patterns, hypothesize root causes, and recommend specific guardrail threshold or policy adjustments to reduce review queue noise without increasing risk.

## INPUT DATA
You will receive a JSON array of escalation records. Each record has already been adjudicated by a human reviewer.

[ESCALATION_RECORDS]

## TASK
1. **Categorize False Positives:** Group the false positive records into 3-5 distinct pattern categories based on the common reason the guardrail was incorrectly triggered (e.g., "Overly sensitive toxicity filter on technical jargon," "Context-blind PII detection on code examples").
2. **Root Cause Analysis:** For each category, state the most likely root cause. Consider prompt instruction ambiguity, guardrail threshold calibration, missing context, and adversarial vs. benign intent confusion.
3. **Impact Assessment:** For each category, estimate the impact on reviewer time and the potential risk of a true positive being missed if the guardrail were relaxed.
4. **Threshold Adjustment Recommendations:** Propose specific, actionable adjustments. These can be:
    - **Numerical:** "Increase the toxicity confidence threshold from 0.7 to 0.85."
    - **Contextual:** "Add a pre-check: if the input is a code block, bypass the PII guardrail."
    - **Policy-Based:** "Update the [POLICY_NAME] guardrail description to explicitly exclude [BENIGN_CATEGORY]."
5. **Confidence Score:** For each recommendation, provide a confidence score (Low/Medium/High) that the change will reduce false positives without introducing a new blind spot.

## CONSTRAINTS
- Do not recommend disabling a guardrail entirely unless you can prove it has a 100% false positive rate with zero risk.
- Base all analysis strictly on the provided records. Do not hallucinate external data.
- If the data is insufficient to identify a pattern, state that explicitly instead of forcing a conclusion.
- Prioritize recommendations that have the highest impact-to-risk ratio.

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "analysis_summary": "A 2-3 sentence executive summary of findings.",
  "false_positive_categories": [
    {
      "category_name": "string",
      "record_count": "number",
      "common_trigger": "string (the guardrail that fired)",
      "root_cause_hypothesis": "string",
      "reviewer_time_wasted_estimate": "string (e.g., '~4 hours/week')",
      "risk_of_relaxation": "string (description of what true positive might be missed)",
      "recommended_adjustments": [
        {
          "type": "threshold | context_rule | policy_update",
          "description": "string",
          "implementation_notes": "string",
          "confidence": "Low | Medium | High"
        }
      ]
    }
  ],
  "data_quality_notes": "string (any issues with the input data that affect analysis)",
  "overall_recommendation_priority": ["string (ordered list of top 3 actions to take)"]
}

To adapt this template, replace [ESCALATION_RECORDS] with your actual data payload. Ensure the input records contain at minimum: the original prompt/response, the guardrail name and version, the violation reason, and the human adjudication label. If your system uses different terminology (e.g., 'anomaly' instead of 'violation'), update the prompt language accordingly. The output schema is strict JSON; if your application layer requires a different format, modify the OUTPUT_SCHEMA section but keep the analytical steps intact. For high-stakes guardrails (e.g., child safety, self-harm), add a [RISK_LEVEL] constraint that forces a 'High' confidence requirement and mandates a second human review of any recommended relaxation before implementation.

This prompt is designed to operate as a batch analysis step within a trust and safety review queue system. It should be invoked periodically (e.g., daily or weekly) against a sample of adjudicated escalations where human reviewers marked the escalation as a false positive. The prompt requires a structured input payload containing the original escalation context, the reviewer's adjudication outcome, and any relevant policy definitions. The output is a structured analysis record that can be ingested by a dashboard or fed into a threshold-tuning workflow.

To wire this into an application, build a pre-processing step that queries your review database for false positive cases within the analysis window. Construct the [INPUT] payload as a JSON object containing an array of case objects, each with case_id, escalation_reason, model_confidence, reviewer_outcome, and evidence_excerpt. Pass this payload along with the [POLICY_CONTEXT] and [THRESHOLD_CONFIG] into the prompt template. On the output side, implement a JSON schema validator to ensure the response contains the required fields: patterns_identified, root_cause_hypotheses, threshold_adjustment_recommendations, and confidence_analysis. If validation fails, retry once with a repair prompt that includes the validation error message. Log all raw responses and validation outcomes for auditability.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window, as the analysis requires holding multiple cases in memory to identify cross-case patterns. For high-stakes policy environments, route the output to a human analyst for review before applying any threshold changes. Store the final analysis alongside the source cases in your governance database. Avoid the temptation to auto-apply threshold recommendations without human approval, as false positive reduction can inadvertently increase false negatives if not carefully calibrated against your organization's risk tolerance.