Verification Triage Model Fallback Prompt

This prompt is designed for a single, critical job: producing a safe routing decision when your primary verification triage model is unavailable. The trigger is a circuit breaker event—specifically, when the primary model call exceeds a predefined latency budget (e.g., 2000ms), returns a non-2xx HTTP status, or produces an output that fails schema validation against the expected TriageDecision contract. In these degraded-mode scenarios, the system must not halt; it must fall back to a simpler, more reliable path that prioritizes auditability and human safety over cost or speed optimization.

The core operational principle is 'default to human review.' The fallback prompt is intentionally constrained to avoid making high-confidence automated decisions with a less capable model or heuristic. It should be invoked inside a dedicated circuit breaker service that catches primary model failures. The service must log the failure reason, the latency at failure, and the raw (or null) primary response before invoking this fallback. This ensures a complete audit trail. Do not use this prompt as a cost-saving measure to replace the primary triage model during normal operations; it is strictly a safety net for when the primary path is broken.

Before deploying, you must define the [FALLBACK_MODEL] (e.g., a lightweight classifier or a fast, cheap LLM) and the [HUMAN_REVIEW_QUEUE] endpoint. The prompt's instructions force the model to output a constrained routing_decision enum (HUMAN_REVIEW or LOW_RISK_AUTO_VERIFY). The LOW_RISK_AUTO_VERIFY path should only be taken when the claim is trivially verifiable against the provided [EVIDENCE_SNIPPETS] and carries zero risk of harm. Any ambiguity, missing evidence, or high-risk topic must force the HUMAN_REVIEW route. After implementing this prompt, your next step is to build a monitoring dashboard that tracks the fallback activation rate, the ratio of HUMAN_REVIEW vs LOW_RISK_AUTO_VERIFY decisions made by the fallback, and the latency of the fallback path itself to ensure it stays within the degraded-mode SLA.

This prompt acts as a safety net when your primary verification triage model is unavailable, times out, or returns malformed output. Instead of silently dropping the claim or routing it blindly, the fallback prompt produces a conservative routing decision that prioritizes human review for anything ambiguous. The template is designed to work with faster, cheaper models (such as a quantized local model or a lightweight cloud endpoint) and can also serve as a specification for a heuristic rule engine if you decide to replace the fallback model entirely.

textCopy
You are a fallback verification triage router. The primary triage model is unavailable or has exceeded its latency budget. Your job is to make a safe, conservative routing decision using only the information provided below. You must never auto-verify a claim when evidence is missing, ambiguous, or insufficient.

[INPUT]
Claim: [CLAIM_TEXT]
Claim Source: [SOURCE_DESCRIPTION]
Claim Domain: [DOMAIN]
Available Evidence Count: [EVIDENCE_COUNT]
Evidence Summary: [EVIDENCE_SUMMARY]
Primary Model Failure Reason: [FAILURE_REASON]

[CONSTRAINTS]
- If [EVIDENCE_COUNT] is 0, route to HUMAN_REVIEW.
- If [EVIDENCE_COUNT] is 1 and the single source is not authoritative for [DOMAIN], route to HUMAN_REVIEW.
- If [FAILURE_REASON] indicates a timeout and [EVIDENCE_COUNT] >= 2 from authoritative sources, you may route to AUTO_VERIFY only if the evidence summary clearly supports or contradicts the claim without ambiguity.
- If [DOMAIN] is in [HIGH_RISK_DOMAINS], always route to HUMAN_REVIEW regardless of evidence count.
- If the claim contains numerical assertions and no numerical evidence is present in the summary, route to HUMAN_REVIEW.
- Never invent evidence or assume missing information supports the claim.

[OUTPUT_SCHEMA]
Return ONLY valid JSON with this exact structure:
{
  "routing_decision": "AUTO_VERIFY" | "HUMAN_REVIEW",
  "confidence": "LOW" | "MEDIUM",
  "reasoning": "Brief explanation of the decision based on the constraints above.",
  "fallback_triggered": true,
  "escalation_reason": "[FAILURE_REASON]" | "INSUFFICIENT_EVIDENCE" | "HIGH_RISK_DOMAIN" | "NUMERICAL_CLAIM_NO_EVIDENCE" | "SINGLE_NON_AUTHORITATIVE_SOURCE"
}

Adapt this template by replacing the bracketed placeholders with values from your verification pipeline. The [HIGH_RISK_DOMAINS] placeholder should be populated from your organization's risk registry—common examples include medical claims, legal interpretations, financial projections, and safety-related assertions. If you are using this as a specification for a heuristic rule engine rather than a model prompt, translate each constraint into an if-then rule with the same conservative bias toward human review. Test the fallback path regularly by simulating primary model failures in staging and measuring whether the fallback routing decisions match the primary model's decisions for clear-cut cases while correctly escalating ambiguous ones. The most dangerous failure mode is a fallback that silently auto-verifies a claim the primary model would have escalated—your eval suite must include adversarial test cases designed to catch exactly that.

The Verification Triage Model Fallback Prompt is not a standalone prompt—it is a circuit breaker inside a larger orchestration layer. When the primary triage model exceeds a latency budget (e.g., 800ms p95), returns a malformed response that fails validation, or throws a provider error, the harness must catch that failure and invoke this fallback prompt on a simpler, faster model or a local heuristic path. The fallback's job is to produce a safe routing decision that avoids the worst failure mode: silently auto-verifying a high-risk claim because the primary path died. The harness should treat the fallback as a degraded-mode decision, not a substitute for the primary model's reasoning quality.

Wire the fallback prompt behind a timeout and retry wrapper. On the primary path, set a strict deadline (e.g., 700ms for OpenAI, 900ms for Claude) and a single retry with exponential backoff. If the primary model fails or times out, immediately invoke the fallback prompt on a lightweight model such as gpt-4o-mini or claude-3-haiku with a shorter timeout (e.g., 500ms). The fallback prompt must receive the same [CLAIM], [CONTEXT], and [EVIDENCE_SNIPPETS] as the primary, but its output schema should be simpler: a single routing_decision enum (HUMAN_REVIEW, LOW_RISK_AUTO_VERIFY, ESCALATE) plus a confidence score and a reason string. Validate the output strictly: if the enum is missing or the confidence is below a configurable threshold (default 0.7), force-route to HUMAN_REVIEW. Log every fallback invocation with the primary failure reason, the fallback model used, the routing decision, and the latency delta so operators can monitor degradation frequency.

Do not let the fallback path become a silent auto-verification backdoor. The harness must enforce a hard rule: if the fallback returns LOW_RISK_AUTO_VERIFY, the system must still check whether the claim contains any high-risk markers (e.g., medical, legal, financial, safety) from a pre-computed risk classifier or keyword list. If high-risk markers are present, override the fallback decision to HUMAN_REVIEW and log the override. This prevents a degraded model from accidentally green-lighting dangerous claims. Additionally, instrument the fallback path with a counter metric and an alert threshold—if more than 5% of requests hit the fallback in a rolling 5-minute window, page the on-call engineer to investigate the primary model or provider. The fallback is a safety net, not a permanent operating mode.