Error Handling Policy to Repair Example Prompt

This prompt is designed for production engineers who need to teach a model how to repair malformed outputs, apply retry logic, or execute fallback behavior without restating the full error handling policy as procedural instructions. The core job-to-be-done is converting a stable, written policy into a compact set of broken-output to fixed-output demonstration pairs. These examples replace hundreds of tokens of rules with concrete before-and-after patterns, making the model's repair behavior more consistent and reducing per-request token costs. The ideal user is an engineer who already has a documented error handling policy and needs the model to internalize repair patterns rather than follow step-by-step instructions that can be brittle or ignored.

Use this approach when your error handling policy is stable enough to be captured in examples, when you need to reduce token costs by swapping verbose policy text for targeted demonstrations, and when the repair actions are deterministic enough that a well-chosen example set can cover the majority of production failure modes. This prompt is particularly effective for output repair loops where the same validation errors occur repeatedly—malformed JSON, missing required fields, incorrect enum values, or schema violations that follow predictable patterns. The resulting example set can be embedded directly in a system prompt or injected into a retry context, giving the model concrete patterns to follow without re-explaining the policy each time. You should also use this when you want to version-control your repair behavior as data (the example set) rather than as prompt text, making it easier to test, diff, and roll back changes.

Do not use this prompt when the error handling policy changes frequently, as the example generation and validation cycle will create unacceptable maintenance overhead. Avoid it when errors require real-time human judgment—for instance, when a repair action involves irreversible side effects like sending an email, modifying a database record, or making a financial transaction without a human approval gate. In these cases, the prompt should generate an escalation or hold-for-review signal rather than a repair example. Also avoid this approach when the policy is too complex to be captured in a reasonable number of examples; if you need more than 15-20 demonstration pairs to cover the policy, the examples may become contradictory or the model may struggle to generalize. In that scenario, consider breaking the policy into smaller, composable repair prompts or investing in programmatic validation and repair logic in the application layer instead.

This template converts a natural-language error handling policy into a set of corrective few-shot examples. Instead of describing retry logic, fallback behavior, and repair patterns in prose, you provide the policy and constraints, and the model produces demonstration pairs that teach the desired behavior through worked examples. Each pair shows a broken or invalid output alongside the corrected version, making the repair pattern explicit for downstream models.

textCopy
You are an expert prompt engineer converting an error handling policy into corrective demonstration pairs.

Your task is to read the provided error handling policy and produce a set of broken-output to fixed-output example pairs that teach the repair patterns, retry logic, and fallback behavior described in the policy.

## INPUT

Error Handling Policy:
[POLICY_TEXT]

## CONSTRAINTS

- Each example pair must show a realistic broken output and its corrected version.
- Cover all distinct error categories mentioned in the policy.
- Include at least one example per retry scenario, one per fallback scenario, and one per escalation scenario.
- Broken outputs must reflect plausible model failures, not random noise.
- Fixed outputs must strictly follow the repair rules in the policy.
- Do not add repair behaviors not present in the policy.
- If the policy specifies human review for certain error types, include an example where the fixed output is an escalation message rather than a repair attempt.

## OUTPUT FORMAT

Return a JSON object with an "examples" array. Each element must have:
- "error_category": the error type from the policy
- "broken_output": the invalid model response
- "fixed_output": the corrected response following the policy
- "repair_action": one of "retry", "fallback", "escalate", or "self_correct"
- "policy_reference": the specific clause or rule from the policy that applies

## EXAMPLE PAIR STRUCTURE

{
  "error_category": "schema_validation_failure",
  "broken_output": "{ \"name\": null, \"value\": \"abc\" }",
  "fixed_output": "{ \"name\": \"UNKNOWN\", \"value\": \"abc\", \"confidence\": 0.0 }",
  "repair_action": "self_correct",
  "policy_reference": "Section 3.2: Null fields must be replaced with sentinel values and confidence set to 0.0"
}

Generate the full set of demonstration pairs now.

To adapt this template, replace [POLICY_TEXT] with your actual error handling rules. The policy should be specific enough to extract distinct error categories, repair actions, and escalation criteria. If your policy is long, consider splitting it into sections and running the prompt once per section to keep example sets focused. After generation, validate that every policy clause is covered by at least one example pair and that no repair action contradicts the written policy. For high-risk production systems, have a human reviewer spot-check the generated pairs before using them to train downstream behavior.

This prompt converts error-handling policies into corrective demonstration pairs, but its real value emerges when it's embedded in a repair harness—a pipeline that catches a model's malformed output, feeds the error and the original context into this prompt, and uses the generated examples to guide a second model call. The harness should treat the prompt's output as a structured artifact: a set of broken-output to fixed-output pairs that can be cached, versioned, and audited. Do not use this prompt as a one-off fix; wire it into a loop where validation failures trigger example generation, and the examples are appended to the retry prompt's few-shot block.

The implementation should follow a validate → generate → retry → escalate pattern. First, run the primary model's output through a deterministic validator (schema check, regex, field presence). On failure, call this prompt with the [ERROR_HANDLING_POLICY], the [FAILED_OUTPUT], and the [VALIDATION_ERROR]. Parse the resulting repair examples and inject them into a retry prompt that includes the original [INPUT], the [OUTPUT_SCHEMA], and a [CONSTRAINTS] block. Set a maximum of two retries before escalating to a human review queue or a fallback model. Log every repair attempt with the error type, the generated examples, and the final outcome to build a dataset for future fine-tuning or policy refinement.

Avoid wiring this prompt directly into a customer-facing response without a human review gate if the error involves regulated data, financial calculations, or clinical information. The generated repair examples are themselves model outputs and can contain subtle hallucinations—especially when the policy document is long or ambiguous. Before deploying, run a regression suite: take 20 known failure cases, generate repair examples, and measure whether the retry loop resolves them without introducing new errors. If the repair success rate drops below 90%, revisit the policy document for clarity or add a human-in-the-loop step before the final output is released.