Out-of-Distribution Detection Example Prompt

This prompt is designed for production engineers who need a model to signal 'I don't know' reliably when it encounters inputs outside its expected distribution. The primary job-to-be-done is graceful abstention: instead of hallucinating a confident but incorrect answer for a novel category, adversarial input, or drifted data, the model returns a controlled rejection that your application can route to a fallback queue, human review, or a specialized classifier. Use this prompt when you are building a classification, extraction, or Q&A system that must handle open-world inputs in production, and you need a prompt-level safety net that works alongside your existing monitoring tools.

The ideal user is an engineering lead or ML engineer who already has production traffic and understands their model's known categories or expected input shapes. You should have a defined set of in-distribution classes, schemas, or topics, plus a clear escalation path for rejected inputs. This prompt works best when you provide concrete examples of both in-distribution and out-of-distribution inputs, showing the model exactly where the boundary lies. It is not a replacement for a dedicated OOD classifier model, a statistical drift detection system, or an embedding-based nearest-neighbor check. Think of it as the last line of defense inside the prompt itself, catching what your upstream guards may miss.

Do not use this prompt when you need guaranteed OOD detection with measurable false-positive rates, when your input distribution is too large to represent in a few-shot example set, or when the cost of a missed OOD input is catastrophic without human review. In high-stakes domains like healthcare triage or financial compliance, this prompt should feed a human review queue rather than make autonomous rejection decisions. For adversarial robustness, pair this prompt with a dedicated red-teaming eval suite and monitor the false-positive OOD flagging rate over time. If your production traffic shifts, update the in-distribution examples to prevent the model from treating new valid categories as out-of-distribution.

This template teaches a model to recognize inputs that fall outside its expected distribution and respond with appropriate abstention or escalation rather than guessing. Use it to generate few-shot examples that demonstrate OOD detection behavior, including false-positive flagging patterns. Replace each square-bracket placeholder with concrete values before sending to the model.

textCopy
You are an example generator for out-of-distribution (OOD) detection training. Your task is to produce input-output pairs that teach a model to recognize when a user request falls outside its intended domain and respond with abstention or escalation.

## Domain Definition
[DOMAIN_DESCRIPTION]

## Expected In-Distribution Behavior
[IN_DISTRIBUTION_BEHAVIOR]

## OOD Response Policy
When an input is out-of-distribution, the model must:
1. State clearly that the request is outside its scope.
2. Explain why briefly without guessing.
3. [ESCALATION_ACTION: e.g., "suggest contacting support", "route to human review", "return an ABSTAIN flag"]

## Example Generation Instructions
Generate [NUM_EXAMPLES] input-output pairs covering these OOD categories:
[OOD_CATEGORIES]

For each example, include:
- `input`: The user request text.
- `ood_category`: The OOD category label.
- `expected_output`: The model's abstention or escalation response.
- `false_positive_risk`: LOW, MEDIUM, or HIGH indicating whether this input could be mistaken for in-distribution.

## Output Format
Return a JSON array of objects with the schema:
[OUTPUT_SCHEMA]

## Constraints
[CONSTRAINTS]

## Seed Examples for Reference
[EXAMPLES]

After copying this template, replace each placeholder with domain-specific values. The [OOD_CATEGORIES] placeholder should list the specific types of out-of-distribution inputs you want examples for, such as topic drift, adversarial inputs, or unsupported languages. The [ESCALATION_ACTION] placeholder defines the concrete behavior the model should exhibit when detecting OOD inputs. Validate generated examples against your production data distribution to ensure the OOD categories match real drift patterns rather than hypothetical edge cases.

Integrating an out-of-distribution (OOD) detection prompt into a production system requires treating it as a classification step within a broader pipeline, not a standalone chat interaction. The prompt should sit between the user input and any downstream processing that assumes in-distribution data. When the model flags an input as OOD, the application must route it to an escalation queue, return a controlled error message, or trigger a fallback workflow—never silently process it as if it were in-distribution. This harness must be stateless and idempotent: the same input should produce the same OOD decision regardless of conversation history or system state, unless the distribution definition itself has been updated.

Wire the prompt into your application as a pre-processing guard. Construct the model request by injecting the current [INPUT] and your curated [IN_DISTRIBUTION_EXAMPLES] into the template. Choose a fast, cost-effective model for this classification task (e.g., a small Claude Haiku or GPT-4o-mini tier) since OOD detection is a gating decision, not a generation task. Set temperature=0 to maximize deterministic behavior. Parse the response strictly: expect a JSON object with an ood_flag boolean and a confidence float. Implement a validation layer that rejects any response missing these fields or containing malformed JSON. If validation fails, retry once with the same request; if it fails again, default to ood_flag=true and escalate—failing open on OOD detection is safer than letting an anomalous input through unexamined.

Log every OOD decision with the input hash, model response, confidence score, and routing outcome. This log becomes your drift detection dataset. Periodically compare the distribution of flagged inputs against your known in-distribution examples to detect shifts in production traffic. If the OOD flag rate spikes or drifts beyond an acceptable threshold, trigger an example set refresh workflow. For high-risk domains (healthcare, legal, finance), route all OOD-flagged inputs to a human review queue with the model's confidence score and the closest-matching in-distribution examples for context. Never auto-escalate based solely on the model's ood_reason string—that field is for human interpretability, not programmatic control flow. The harness should treat the model's output as a strong signal, not an infallible gate.