Retry Budget for Refusal Recovery Prompt

This prompt is designed for safety engineers and product managers who need to recover from AI refusals that block legitimate user requests. It operates as a second-stage recovery prompt, invoked after an initial refusal is detected. The prompt instructs the model to re-evaluate the original request against a provided safety policy, clarify the boundary, and either fulfill the request within policy limits or escalate with a precise reason. Use this when your application's safety layer is overly conservative, causing false-positive refusals that degrade user experience. Do not use this prompt to bypass genuine safety constraints or to handle requests that fall into clearly prohibited categories.

The retry budget is the critical control mechanism here. You must define a hard limit on how many times this recovery prompt can be invoked for a single user request. A budget of one to two recovery attempts is typical; exceeding this without a change in outcome signals a genuine policy boundary or an ambiguous edge case that requires human review. Each retry consumes tokens and latency, so the budget should be paired with a circuit breaker: if the model produces the same refusal reason twice, or if the recovery attempt introduces a new, unrelated refusal, stop retrying and escalate. Log the original request, the initial refusal reason, the recovery prompt's output, and the escalation decision for audit and policy refinement.

Before wiring this into production, run a set of eval checks that include known legitimate requests that were previously refused, known policy-violating requests that should remain refused, and boundary cases that should escalate. Measure whether the recovery prompt correctly distinguishes between these categories without weakening the safety policy. If you observe the recovery prompt fulfilling requests that your policy explicitly prohibits, increase the specificity of the policy text in the prompt or reduce the retry budget to zero for those categories. The goal is not to eliminate refusals but to make them precise and auditable.

This prompt template acts as a safety-aware retry governor. It receives a previously refused request, the model's original refusal reason, and the retry budget parameters. Its job is to decide whether the refusal was correct, whether the request can be clarified and re-attempted within the remaining budget, or whether the budget is exhausted and escalation is required. Use this as a system message in a follow-up turn after a refusal event. The prompt is designed to preserve safety boundaries while preventing over-refusal from degrading legitimate user workflows.

textCopy
You are a refusal recovery evaluator operating within a strict retry budget. Your task is to analyze a previously refused request and determine the next action.

## INPUT
- Original Request: [ORIGINAL_REQUEST]
- Refusal Reason Given: [REFUSAL_REASON]
- Safety Policy Context: [SAFETY_POLICY]
- Retry Budget: [MAX_RETRIES] total attempts allowed for this request
- Attempts Used So Far: [ATTEMPTS_USED]
- Remaining Budget: [REMAINING_RETRIES]

## CLASSIFICATION RULES
1. **Correct Refusal**: The request clearly violates the safety policy. Do not re-attempt. Escalate with rationale.
2. **Ambiguous Boundary**: The request falls in a gray area of the policy. If budget remains, clarify the boundary and re-attempt. If budget is exhausted, escalate.
3. **Over-Refusal**: The request does not violate the policy and was incorrectly refused. If budget remains, re-attempt with corrected policy interpretation. If budget is exhausted, escalate.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "decision": "REATTEMPT" | "ESCALATE",
  "classification": "CORRECT_REFUSAL" | "AMBIGUOUS_BOUNDARY" | "OVER_REFUSAL",
  "rationale": "string explaining the classification and decision",
  "recovery_instructions": "string with clarified policy boundary and re-attempt guidance, only if decision is REATTEMPT",
  "escalation_payload": {
    "severity": "LOW" | "MEDIUM" | "HIGH",
    "summary": "string summarizing the refusal and budget state",
    "recommended_action": "string describing what a human reviewer should do",
    "retry_history": [
      {
        "attempt": number,
        "refusal_reason": "string",
        "recovery_action": "string or null"
      }
    ]
  }
}

## CONSTRAINTS
- Never re-attempt a correctly refused request, regardless of remaining budget.
- Never weaken the safety policy to accommodate a refused request.
- If the budget is exhausted, always escalate regardless of classification.
- Include the full retry history in every escalation payload.
- For AMBIGUOUS_BOUNDARY cases, the recovery instructions must clarify which policy interpretation applies.
- For OVER_REFUSAL cases, the recovery instructions must correct the misinterpretation without weakening the policy.

To adapt this template, replace the square-bracket placeholders with values from your application harness. [ORIGINAL_REQUEST] should contain the exact user input that was refused. [REFUSAL_REASON] should capture the model's stated reason for refusal, not a paraphrase. [SAFETY_POLICY] should include the relevant policy text that governs the refusal decision. The retry budget parameters [MAX_RETRIES], [ATTEMPTS_USED], and [REMAINING_RETRIES] must be tracked by your application layer and injected accurately—do not rely on the model to count retries. Before deploying, validate that the output JSON matches the schema exactly, especially the decision enum and the conditional presence of recovery_instructions. For high-risk domains, route all ESCALATE decisions with HIGH severity to a human review queue and log the full escalation_payload for audit. Test this prompt against a golden set of known correct refusals, known over-refusals, and ambiguous boundary cases to verify that it never re-opens a correctly refused request.

The Retry Budget for Refusal Recovery Prompt is not a standalone safety filter—it is a decision node inside a larger refusal-recovery harness. The harness must track the number of recovery attempts per request, enforce a hard budget, and prevent the recovery loop from weakening the original safety boundary. Wire this prompt into your application as a post-refusal recovery step: when the primary safety prompt or classifier returns a refusal, the harness invokes this prompt with the original request, the refusal reason, and the current retry count. The prompt's job is to decide whether the refusal was correct (escalate), clearly incorrect (re-attempt with clarified policy), or genuinely ambiguous (escalate to human review). The harness, not the prompt, enforces the budget ceiling and terminates the loop.

Implement the harness as a stateful retry loop with three hard gates. First, maintain a refusal_recovery_attempts counter scoped to the original request ID; increment it before each invocation of the recovery prompt. Second, enforce a configurable MAX_REFUSAL_RECOVERY_ATTEMPTS (start with 2–3 for most production systems) and immediately route to the escalation path when the counter exceeds it, without invoking the prompt again. Third, validate the prompt's output against a strict schema—expect fields like decision (enum: REATTEMPT, ESCALATE_SAFETY, ESCALATE_AMBIGUOUS, ESCALATE_BUDGET_EXHAUSTED), clarified_policy_boundary (string, required for REATTEMPT), and rationale (string, required for all decisions). Reject any output that does not conform and treat the rejection as a budget-consuming failure. Log every decision, the retry count, the refusal reason, and the recovery prompt's rationale to an audit trail for safety-boundary regression testing.

Model choice matters here. Use a model with strong instruction-following and safety reasoning for the recovery prompt—the same model that produced the original refusal is acceptable if it demonstrates consistent policy reasoning, but consider routing to a separate, equally capable model for the recovery step to avoid compounding the same policy misinterpretation. The harness should also implement a circuit breaker: if the recovery prompt returns REATTEMPT but the re-attempted request produces an identical refusal reason, treat that as a signal of policy boundary disagreement and escalate immediately, consuming the remaining budget. Finally, never allow the recovery prompt to modify the core safety policy itself—the [SAFETY_POLICY] placeholder must be injected by the harness from an immutable policy store, not derived from the model's output. The next step after implementing this harness is to build a regression suite of known refusal edge cases (legitimate refusals, over-refusals, and ambiguous boundary requests) and measure whether the recovery loop correctly escalates each category without increasing unsafe completions.