Escalation Threshold Prompt for Unrepairable Output

This prompt is designed for reliability engineers and platform architects who need a deterministic, auditable decision point at the end of a self-correction harness. Its primary job is to prevent infinite repair loops when a model's structured output has failed validation after multiple retries. The ideal user is someone integrating a large language model (LLM) into a production pipeline where downstream systems—such as JSON parsers, API gateways, or database ingestion scripts—will reject any malformed payload. The required context includes the original failed output, the complete history of repair attempts and their specific validation errors, the target schema, and a defined retry budget. Without this context, the prompt cannot accurately assess the risk of semantic drift or the cost of further attempts.

You should use this prompt when a repair loop has exhausted its allocated retries without producing a valid output, or when the nature of the validation errors suggests that further automated repair is likely to corrupt the original semantic intent. For example, if a JSON repair prompt has fixed trailing commas and type mismatches but continues to fail on a complex enum violation that requires domain knowledge, this escalation prompt should be invoked. It is not a general-purpose error handler. Do not use it for transient infrastructure errors like API timeouts or rate limits, which should be handled by a separate retry-with-backoff strategy. It is also inappropriate for simple, first-attempt validation failures where a single retry with error context is the standard and cost-effective solution.

The prompt's value lies in its structured output: an escalation decision with a reason code (e.g., REPAIR_BUDGET_EXHAUSTED, SEMANTIC_DRIFT_DETECTED, IRREPARABLE_STRUCTURE). This deterministic output is designed to be consumed by an application router, not a human reader. The next step after receiving an escalation decision is to programmatically route the failed payload and its repair history to a dead-letter topic, a human review queue, or a fallback model. Avoid the temptation to use this prompt as a diagnostic tool for prompt engineering; its purpose is to protect system stability by enforcing a hard stop on a failing process.

This prompt template is designed to be the final gate in a structured output repair loop. After your validator has rejected a model response and your retry budget is exhausted, this prompt evaluates the remaining error context, the repair history, and the risk of semantic drift to produce a structured escalation decision. It is not a repair prompt—it is a decision prompt that tells your harness whether to attempt one more repair, return a partial result, or escalate to a human operator with a clear reason code.

textCopy
You are an escalation decision engine for a production AI repair pipeline. Your job is to evaluate a failed structured output and decide whether further automated repair is safe and likely to succeed, or whether the output must be escalated to a human reviewer.

## INPUTS
- Original Prompt: [ORIGINAL_PROMPT]
- Failed Output: [FAILED_OUTPUT]
- Target Schema: [OUTPUT_SCHEMA]
- Validation Errors: [VALIDATION_ERRORS]
- Repair Attempts So Far: [REPAIR_ATTEMPT_COUNT]
- Previous Repair Actions: [REPAIR_HISTORY]
- Retry Budget Remaining: [RETRY_BUDGET_REMAINING]
- Risk Level of Downstream Action: [RISK_LEVEL]

## DECISION RULES
1. If the validation errors are purely syntactic (trailing commas, unquoted keys, bracket mismatches) and repair attempts < 2, decide REPAIR.
2. If the errors involve missing required fields with no inferable values from context, decide ESCALATE with reason code MISSING_REQUIRED_DATA.
3. If previous repairs introduced semantic drift (values changed meaning, not just format), decide ESCALATE with reason code SEMANTIC_DRIFT.
4. If the retry budget is exhausted, decide ESCALATE with reason code RETRY_BUDGET_EXHAUSTED.
5. If the risk level is HIGH and any repair confidence would be below 0.9, decide ESCALATE with reason code HIGH_RISK_LOW_CONFIDENCE.
6. If partial output is acceptable per [PARTIAL_OUTPUT_ALLOWED] and some fields are valid, decide PARTIAL with a list of valid fields.
7. Otherwise, decide REPAIR with specific fix instructions.

## OUTPUT FORMAT
Return a JSON object with exactly this structure:
{
  "decision": "REPAIR" | "ESCALATE" | "PARTIAL",
  "reason_code": "SYNTACTIC_ONLY" | "MISSING_REQUIRED_DATA" | "SEMANTIC_DRIFT" | "RETRY_BUDGET_EXHAUSTED" | "HIGH_RISK_LOW_CONFIDENCE" | "PARTIAL_SALVAGE_POSSIBLE",
  "confidence": 0.0-1.0,
  "repair_instructions": "string or null",
  "valid_fields": ["field_names"] or null,
  "escalation_message": "string or null",
  "rationale": "Brief explanation of the decision"
}

## CONSTRAINTS
- Do not invent missing data. If a required field cannot be inferred from context, escalate.
- If the original intent of [ORIGINAL_PROMPT] is unclear due to output corruption, escalate.
- For HIGH risk_level, prefer escalation over repair when confidence is uncertain.
- Never return a REPAIR decision without specific, actionable repair_instructions.

To adapt this template, wire the [ORIGINAL_PROMPT], [FAILED_OUTPUT], and [VALIDATION_ERRORS] placeholders directly from your repair loop's state. The [REPAIR_ATTEMPT_COUNT] and [RETRY_BUDGET_REMAINING] should be tracked by your harness, not the model. Set [RISK_LEVEL] based on the downstream action—use HIGH for financial transactions, clinical data, or legal filings; MEDIUM for customer-facing content; LOW for internal drafts. The [PARTIAL_OUTPUT_ALLOWED] boolean should be a harness-level configuration flag that controls whether partial salvage is acceptable in your product context.

After receiving the model's decision, your harness should branch: route REPAIR decisions back to your repair prompt with the provided repair_instructions appended as additional constraints; route PARTIAL decisions to your partial salvage handler with the valid_fields list; route ESCALATE decisions to your human review queue with the escalation_message and full error context. Log every decision with the reason_code and confidence for observability. Never bypass an ESCALATE decision automatically—if the model says a human is needed, respect that boundary.

The escalation threshold prompt is not a standalone decision engine—it is the final gate in a structured output repair pipeline. It should be invoked only after a repair loop has exhausted its retry budget or encountered a failure mode that the repair prompts cannot address. The prompt expects a structured summary of the repair history, including the original error, the number of repair attempts, the validator error messages from each attempt, and the current unrepaired output. This context is critical because the model must weigh semantic drift risk against the cost of further retries, not guess what went wrong.

Wire this prompt into your application as a synchronous decision point between the repair loop and the downstream consumer. After each repair attempt, increment a retry counter and append the validator output to a repair log. When the counter exceeds a configured maximum (e.g., 3 attempts) or a validator returns a non-repairable error code (such as a schema version mismatch or a required field that cannot be inferred), call this prompt with the full repair log. Parse the response into a structured escalation decision object containing action (one of repair, partial_salvage, escalate, abort), reason_code, confidence, and recommended_recipient if escalation is required. Validate this output against a strict schema before acting on it—a malformed escalation decision is itself an escalation trigger.

For high-risk domains such as healthcare, finance, or legal workflows, always route escalate and partial_salvage decisions to a human review queue. Do not automatically discard output or continue with partial results without human approval when the reason code indicates semantic drift risk, missing required fields, or evidence-grounding failures. Log every escalation decision with the full repair history, the prompt version, the model used, and the final action taken. This audit trail is essential for debugging brittle repair loops and demonstrating governance to reviewers. Avoid the temptation to increase the retry budget indefinitely—if the escalation prompt returns repair but the next attempt fails identically, treat that as a loop and escalate immediately.