Fabricated Detail Detection Prompt Template

This prompt is designed for a single, high-stakes job: identifying specific, verifiable details in a generated text that are completely absent from the provided source context. It targets concrete entities like names, numbers, dates, URLs, and unique identifiers—the kind of fabricated details that are objectively wrong and can erode user trust or cause compliance failures. The ideal user is an AI safety engineer or a developer building an output validation guardrail, not an end-user. You should use this prompt when you have a model-generated output and a defined, closed set of source documents or context passages that should have contained all necessary information.

This prompt is not a general-purpose hallucination detector. It will not catch subtle paraphrasing errors, logical contradictions, or unsupported opinions. It is laser-focused on 'hard' fabrications: a phone number that doesn't exist in the source, a person's name that was invented, or a date that was never mentioned. Use it as a first-pass filter in a broader validation pipeline, placed immediately after text generation and before the output reaches a user or another system. The prompt requires a clear [CONTEXT] and [GENERATED_OUTPUT] to compare. Without a well-defined, authoritative context, the detection is meaningless. Do not use this prompt to evaluate creative writing, subjective analysis, or outputs where the source material is intentionally incomplete.

Before deploying, you must pair this prompt with a structured output schema and a validation harness. The prompt is designed to return a list of fabricated spans with confidence scores, which your application code can then parse and act upon. The next step is to integrate this into your application layer where you can set thresholds for blocking, flagging for human review, or logging for offline analysis. Avoid the temptation to use this prompt in isolation without a clear action policy for what happens when a fabrication is detected.

This prompt template is designed to be integrated into an output validation guardrail. Its job is to compare a generated text against a set of source documents and identify specific spans—names, numbers, dates, URLs, or entity references—that appear in the output but cannot be traced to any provided context. The template uses square-bracket placeholders so you can wire it into your application's prompt assembly layer without modification. The core instruction forces the model to act as a strict auditor, returning only verifiable discrepancies rather than generating new analysis.

textCopy
You are a strict output auditor. Your only job is to compare the [GENERATED_OUTPUT] against the [SOURCE_CONTEXT] and identify specific details that appear in the output but cannot be found anywhere in the source context.

## Input

**Generated Output:**
[GENERATED_OUTPUT]

**Source Context (the only allowed evidence):**
[SOURCE_CONTEXT]

## Detection Rules

1. Flag any name, number, date, URL, entity reference, or specific claim that appears in the Generated Output but is absent from the Source Context.
2. Do not flag statements that are reasonable paraphrases of source material.
3. Do not flag opinions, interpretations, or hedging language unless they introduce new factual details.
4. For each flagged detail, extract the exact text span from the Generated Output.
5. For each flagged detail, search the Source Context for the closest supporting evidence. If none exists, mark it as fabricated.
6. Assign a confidence score from 0.0 to 1.0 for each flagged detail, where 1.0 means you are certain the detail is fabricated.

## Output Format

Return a JSON object with this exact schema:

{
  "fabricated_details": [
    {
      "span": "exact text from output",
      "detail_type": "name|number|date|url|entity|claim",
      "confidence": 0.0-1.0,
      "closest_source_match": "best matching source text or null",
      "explanation": "why this detail cannot be found in the source context"
    }
  ],
  "total_fabricated": integer,
  "output_grounding_score": 0.0-1.0
}

## Constraints

- Only return details that are verifiably absent from the Source Context.
- If no fabricated details are found, return an empty fabricated_details array with total_fabricated: 0 and output_grounding_score: 1.0.
- Do not hallucinate fabricated details. If you are unsure, exclude the detail.
- The output_grounding_score should reflect the proportion of factual claims in the Generated Output that are supported by the Source Context.

## Risk Level

[RISK_LEVEL]

## Examples

[EXAMPLES]

To adapt this template for your pipeline, replace the placeholders with your application's actual inputs. [GENERATED_OUTPUT] should receive the text you want to audit—typically the final response from your generation model. [SOURCE_CONTEXT] should contain the concatenated retrieved passages, documents, or knowledge base entries that the generation model was supposed to use. [RISK_LEVEL] is a control parameter: set it to high for regulated domains where false negatives are unacceptable (this should trigger stricter confidence thresholds downstream), or low for exploratory use cases. [EXAMPLES] should contain 2-3 few-shot demonstrations showing both fabricated and non-fabricated cases with correct output JSON. These examples are critical for calibration—without them, the model may over-flag paraphrases or under-flag subtle fabrications. After copying the template, validate that your output parser can handle the exact JSON schema, and run at least 50 labeled test cases through the prompt before deploying to production.

This prompt is designed to operate as a post-generation validation step, not a user-facing feature. In a production application, you will call your primary generation model first, then pass the generated text and the original source context into this detection prompt. The output is a structured list of fabricated spans with confidence scores, which your application must then use to decide whether to block, flag, repair, or escalate the response. Do not rely on this prompt as a real-time streaming guardrail without substantial latency optimization; it is best suited for asynchronous validation or for use in pre-release evaluation pipelines where thoroughness matters more than speed.

Wire the prompt into your application by constructing a validation function that accepts generated_text and source_context as inputs. The function should format the prompt template with these values, call a capable model (GPT-4o or Claude 3.5 Sonnet are strong defaults for this structured extraction task), and parse the JSON output into a list of fabricated detail objects. Implement a validation layer that checks the output schema: each object must have a span, confidence, and reason field. If the model returns malformed JSON, implement a single retry with a stricter format reminder. Log every validation call—including the generated text, source context, detected fabrications, and model used—for audit and debugging. For high-risk domains such as healthcare or legal, route any detection with confidence above 0.5 to a human review queue before the response reaches the user.

When integrating this into a RAG pipeline, call the detection prompt after answer generation but before returning the response to the user. If fabrications are detected, you have several options: block the response entirely and return a fallback message, attempt a repair by prompting the model to regenerate only the flagged spans with stricter grounding instructions, or flag the response for review while still returning it with a warning. Choose your strategy based on the risk tolerance of your application. For customer-facing products where trust is critical, prefer blocking and logging over attempting automatic repair, as repair prompts can introduce new subtle errors. Always include the detection results in your observability traces so you can monitor hallucination rates over time and identify whether retrieval quality or prompt drift is the root cause.