Counterexample-Driven Refusal Prompt for Invalid Inputs

This prompt is for production engineers who need the model to reject inputs that cannot produce valid structured output. It uses positive and negative example pairs to teach refusal boundaries, distinguishing between fixable format issues and unfixable content gaps. Use this when your pipeline must produce a strict JSON schema and you cannot afford hallucinated fields, silent null fills, or best-guess completions on garbage input. This prompt belongs in extraction, normalization, and API payload generation workflows where downstream systems depend on schema compliance.

Deploy this prompt when the cost of a bad output exceeds the cost of no output. Typical triggers include: a downstream database that rejects rows with missing required fields, an API contract that breaks on type mismatches, or a compliance requirement that forbids fabricated values. The prompt is most effective when you can supply at least three positive examples (valid input producing correct structured output) and three negative examples (invalid input producing a structured refusal with a reason code). Do not use this prompt when the input is always well-formed, when a simple JSON Schema validator can catch errors post-generation, or when you can filter invalid inputs upstream with deterministic rules. In those cases, the refusal logic adds token cost and latency without proportional safety gain.

Before wiring this into a production harness, define your refusal contract explicitly. The model should return a consistent refusal structure—such as {"status": "refused", "reason": "...", "input_snippet": "..."}—rather than free-text apologies or empty objects. Pair this prompt with a post-generation validator that checks for the refusal schema and routes refused outputs to a dead-letter queue or human review. If your use case involves regulated data (healthcare, finance, legal evidence), always require human review for refused inputs rather than silently dropping them. Start by running this prompt against a golden dataset of 50–100 inputs that includes known invalid cases, and measure both the refusal rate and the false-refusal rate before promoting to production.

This prompt template teaches the model to distinguish between fixable format issues and unfixable content gaps by providing explicit counterexamples. Instead of relying on lengthy refusal policies, you supply a schema, a few valid input-output demonstrations, and carefully chosen negative examples where the input cannot satisfy the output contract. The model learns to refuse only when extraction is genuinely impossible, reducing both over-refusal on edge cases and hallucinated completions on impossible requests.

textCopy
System: You are a strict extraction engine. Your only job is to produce a valid JSON object matching [OUTPUT_SCHEMA] from the provided [INPUT]. Before outputting JSON, you must classify the input as EXTRACTABLE or UNEXTRACTABLE. If EXTRACTABLE, output the JSON. If UNEXTRACTABLE, output a refusal object with a specific reason code from [REFUSAL_REASONS]. Do not hallucinate missing data. Do not refuse fixable formatting issues.

[OUTPUT_SCHEMA]
{
  "status": "success" | "refused",
  "data": { ... } | null,
  "refusal_reason": string | null
}

[REFUSAL_REASONS]
- MISSING_REQUIRED_FIELD: A field marked required in the schema is absent from the input and cannot be inferred.
- CONFLICTING_VALUES: The input contains contradictory information for the same field.
- OUT_OF_DOMAIN: The input does not contain the type of information the schema expects.
- GARBLED_INPUT: The input is too noisy, truncated, or malformed to parse reliably.

[EXAMPLES]
---
Input: "Name: Jane Doe, Email: jane@example.com"
Output: {"status": "success", "data": {"name": "Jane Doe", "email": "jane@example.com"}, "refusal_reason": null}
---
Input: "Call me tomorrow about the project."
Output: {"status": "refused", "data": null, "refusal_reason": "MISSING_REQUIRED_FIELD"}
---
Input: "Name: John Smith, Email: john@old-company.com, Email: john@new-company.com"
Output: {"status": "refused", "data": null, "refusal_reason": "CONFLICTING_VALUES"}
---
Input: "The quick brown fox jumps over the lazy dog."
Output: {"status": "refused", "data": null, "refusal_reason": "OUT_OF_DOMAIN"}
---
Input: "N@me: J%ne D*e, Em@il: jane@@examp le.com"
Output: {"status": "refused", "data": null, "refusal_reason": "GARBLED_INPUT"}

[INPUT]
{{user_input}}

To adapt this template, replace [OUTPUT_SCHEMA] with your exact target schema, including which fields are required. Populate [REFUSAL_REASONS] with the specific failure modes relevant to your domain—avoid generic categories that blur the line between fixable and unfixable. The [EXAMPLES] block is the most critical section: include at least three positive examples showing successful extraction from varied formats, and at least one counterexample per refusal reason. Place the most common failure mode last in the example list to leverage recency effects. When deploying, log every refusal reason code alongside the input to monitor whether your refusal boundary is too strict or too permissive, and iterate on your counterexamples accordingly.

This prompt is designed to sit behind an API endpoint or queue worker that receives unstructured or semi-structured input and must return either a valid structured object or an explicit refusal. The implementation harness must treat the model's output as untrusted until it passes schema validation and refusal-type checks. Because the prompt uses positive and negative example pairs to teach refusal boundaries, the harness should also monitor the refusal rate over time to detect drift in input quality or model behavior.

Wire the prompt into a pipeline with three stages: pre-validation, model invocation, and post-validation. Pre-validation checks for obviously empty inputs, excessive length, or binary garbage that should never reach the model. Model invocation sends the prompt template with the input inserted into the [INPUT] placeholder, using a low-temperature setting (0.0–0.2) to maximize deterministic refusal behavior. Post-validation parses the model response against the expected output schema and checks for a refusal field or equivalent refusal signal. If the output fails schema validation, log the raw response and the input fingerprint, then retry once with an explicit repair prompt before escalating. If the model returns a valid refusal, route the input to a dead-letter queue or human review bucket depending on the [RISK_LEVEL] configuration.

For high-risk domains such as healthcare or finance, add a human review gate for all refusals and for any output where the model's confidence annotation falls below a configured threshold. Log every invocation with the input hash, model version, prompt version, refusal decision, and latency. Use structured logging so you can build a dashboard that tracks refusal rate, schema compliance rate, and retry rate. Set an alert if the refusal rate shifts by more than 20% week-over-week, as this often signals input distribution drift or a model behavior change. Avoid using this prompt for inputs where a best-effort partial extraction is preferable to a hard refusal—this pattern is for workflows where an incorrect structured output is worse than no output at all.