High-Risk Claim Escalation Prompt Template

This prompt is designed for compliance, trust-and-safety, and verification operations teams who need to identify claims that require immediate human attention. It sits inside a verification pipeline after claim extraction but before evidence matching, acting as a pre-filter to catch high-risk assertions that should never be auto-verified. The primary job-to-be-done is preventing automated systems from silently validating or rejecting claims that carry regulatory penalty, safety incident, or significant reputational risk. The ideal user is a pipeline engineer or operations analyst configuring a verification harness who needs a structured escalation packet—not a free-text alert—that downstream routing and review queues can ingest programmatically.

Use this prompt when the cost of a missed escalation outweighs the cost of human review. Concrete triggers include claims involving imminent physical harm, financial market manipulation, protected-class discrimination, medical contraindications, or legal liability attribution. The prompt assumes you have already decomposed source content into discrete, atomic claims using a prior extraction step. Each claim arrives with its original context span and source identifier. The escalation decision must be made before evidence retrieval to avoid the risk of an auto-verification system incorrectly 'clearing' a dangerous claim against incomplete or outdated evidence. In practice, wire this prompt as a synchronous gate: if the escalation score exceeds your threshold, the claim never reaches the evidence-matching stage and instead generates a reviewer handoff packet.

Do not use this prompt for low-stakes content moderation, general sentiment analysis, or as a standalone classifier outside a verification pipeline. It is not designed to detect toxicity, policy violations in user-generated content, or brand-safety risks unrelated to factual claims. Avoid feeding it raw documents or multi-claim paragraphs; atomicity is a hard prerequisite. If you apply this prompt to claims that have already been auto-verified, you risk confirmation bias where the escalation model defers to the prior verdict. The next step after reading this section should be reviewing the prompt template to understand the exact input schema and output contract, then examining the implementation harness to see how validation, retries, and human-in-the-loop approval gates prevent silent failures.

This prompt is the core instruction set for your escalation workflow. It is designed to be invoked once per claim to keep each risk assessment independent and auditable. The model is instructed to act as a compliance triage specialist, analyzing a single claim and its surrounding context to determine if it meets the criteria for high-risk escalation. The output is a structured JSON packet that can be directly ingested by your review queue or case management system. Before using this template, ensure you have a clear definition of what constitutes a high-risk claim in your operational context, as the prompt's [RISK_CATEGORIES] and [URGENCY_CRITERIA] placeholders must be populated with your organization's specific policies.

textCopy
SYSTEM:
You are a compliance triage specialist. Your task is to evaluate a single claim and its context to determine if it requires immediate human review. You will produce a structured escalation packet.

USER:
Analyze the following claim and its context. Determine if it should be escalated for immediate human review based on the provided risk categories and urgency criteria.

CLAIM: [CLAIM_TEXT]
CONTEXT: [SURROUNDING_CONTEXT]
SOURCE: [SOURCE_DOCUMENT_OR_ORIGIN]

RISK CATEGORIES (escalate if the claim falls into one or more):
[RISK_CATEGORIES]

URGENCY CRITERIA:
[URGENCY_CRITERIA]

OUTPUT_SCHEMA:
{
  "escalate": boolean, // true if the claim requires immediate human review
  "risk_category": string | null, // primary risk category from the provided list
  "potential_harm_description": string | null, // concise description of the potential harm if the claim is false or misleading
  "urgency_level": "critical" | "high" | "medium" | "low", // assessed urgency
  "urgency_rationale": string, // justification for the urgency level based on the criteria
  "escalation_packet": {
    "claim_summary": string, // a one-sentence summary of the claim
    "key_concerns": string[], // list of specific reasons for escalation
    "recommended_reviewer_skill": string | null // suggested expertise for the human reviewer
  } | null
}

CONSTRAINTS:
- Evaluate only the provided claim. Do not introduce external knowledge.
- If the claim does not clearly fall into a risk category, set escalate to false and all other fields to null.
- The potential_harm_description must be specific to the claim, not a generic statement.
- If escalate is false, the escalation_packet must be null.

To adapt this template, replace the square-bracket placeholders with live data from your pipeline. [CLAIM_TEXT] should be the exact, atomic claim extracted from your content. [SURROUNDING_CONTEXT] is the paragraph or section it came from, which is critical for disambiguating intent. [SOURCE_DOCUMENT_OR_ORIGIN] provides traceability. The [RISK_CATEGORIES] placeholder should be replaced with a bulleted list of your organization's defined high-risk categories (e.g., 'incitement to violence', 'regulated financial advice', 'medical misinformation'). Similarly, [URGENCY_CRITERIA] should be replaced with specific, measurable conditions (e.g., 'claim is about an active public safety event', 'claim could cause immediate financial harm'). The output schema is designed to be parsed directly by your application; a null escalation_packet when escalate is false prevents downstream code from accidentally processing an empty review packet. For batch processing, invoke this prompt in a loop, once per claim, to maintain a clean audit trail for each decision.

This prompt is designed to be the final safety net in a verification pipeline, not a standalone classifier. It should be invoked only after a claim has already been flagged by an upstream triage step as potentially high-risk. The harness must enforce this precondition: the prompt must receive a pre-extracted claim, its source context, and any preliminary risk signals. Do not use this prompt on raw, unprocessed content. The model's job is to structure an escalation packet for a human reviewer, not to make the final risk determination.

The implementation harness requires several mandatory validation gates. First, validate that the input [CLAIM] is a single, atomic assertion; reject multi-claim inputs. Second, confirm that [SOURCE_CONTEXT] is present and non-empty to ground the escalation. After the model returns its structured output, validate the JSON schema strictly. The urgency_level field must be one of the predefined enum values (CRITICAL, HIGH, ELEVATED). If the model outputs an invalid urgency level or omits the risk_category, the harness must retry with a stricter output constraint or fall back to a default HIGH urgency with a flag for manual review. Log every retry attempt and schema validation failure for prompt debugging.

This workflow is high-risk, so a human-in-the-loop (HITL) step is mandatory. The escalation packet produced by the prompt must be written to a review queue, never acted upon automatically. The harness should attach a unique escalation_id, a timestamp, and the model version to the packet before queuing it. The review interface should display the original claim, the source context, and the model-generated risk assessment side-by-side, allowing the reviewer to agree, override, or request more evidence. The reviewer's decision and any overrides must be logged as a structured feedback record that can be used to evaluate the prompt's precision and recall over time.

For model choice, use a capable, instruction-following model with strong JSON mode support. Avoid smaller, faster models that may hallucinate risk categories or fail to follow the output schema under pressure. If latency is a concern, implement a two-second timeout with a fallback to a simpler, rule-based escalation that flags the claim as HIGH urgency and routes it directly to the review queue with a note that the AI assessment failed. Never silently drop a claim if the model call fails or times out.

Finally, integrate this prompt into your observability stack. Log the full prompt, the model's raw output, the validated escalation packet, and the eventual human reviewer's disposition. This trace is essential for measuring the prompt's false-escalation rate (claims flagged as high-risk that reviewers dismiss) and its recall (high-risk claims that were missed by upstream triage and never reached this prompt). Use these metrics to tune the upstream triage thresholds and refine the prompt's [RISK_PATTERNS] examples over time.