Domain-Specific Fact Verification Prompt Template

This prompt is designed for accuracy-critical product teams operating in regulated domains such as healthcare, legal, financial services, or technical engineering. Its job is to detect and flag hallucinated facts, fabricated details, and unsupported assertions in model outputs by cross-checking claims against a provided source context and a domain-specific taxonomy. Use this prompt as a post-generation verification step, a retry guard within a self-correction loop, or a pre-human-review filter. It assumes you already have a model-generated statement and the ground-truth source material it should be based on.

The prompt requires three concrete inputs to function: the original model-generated text to audit, the authoritative source context that should ground all claims, and a domain taxonomy defining valid entity types, relationships, and terminology constraints. Without all three, the verification logic degrades—missing context forces the prompt to guess at ground truth, and missing taxonomy prevents it from distinguishing between plausible-sounding fabrications and legitimate domain-specific expressions. In regulated workflows, wire this prompt after every generation step that produces user-facing claims, and log both the verification output and the original context for audit trails.

Do not use this prompt for open-ended creative generation, general chatbot responses, or workflows where source context is unavailable. It is not a substitute for retrieval quality—if your RAG pipeline retrieves irrelevant or incomplete context, this prompt will correctly flag the resulting claims as unsupported, but it cannot fix the retrieval failure itself. For high-stakes domains, always pair this prompt with a human review step when the verification output flags unsupported assertions, and never treat a clean verification result as a guarantee of clinical, legal, or financial correctness.

This template provides the core instruction set for a domain-specific fact verification loop. It is designed to be wrapped in your application's retry harness, invoked after a validator flags unsupported claims in a model's initial output. The prompt instructs the model to act as a skeptical domain auditor, cross-referencing every factual assertion against the provided source context and regenerating a corrected, evidence-grounded response. Before pasting, replace every square-bracket placeholder with the concrete values for your domain, risk tolerance, and output contract.

textCopy
SYSTEM:
You are a [DOMAIN] fact verification auditor operating in a [RISK_LEVEL] environment.
Your only source of truth is the [CONTEXT] provided below.
You must never introduce external knowledge, even if you are confident it is correct.

TASK:
Review the [ORIGINAL_OUTPUT] and identify every factual claim that cannot be verified against the [CONTEXT].
For each unverifiable claim, classify it as:
- FABRICATED: Contradicted by or entirely absent from [CONTEXT].
- UNSUPPORTED: Plausible but lacking sufficient evidence in [CONTEXT].
- MISATTRIBUTED: Cites a source incorrectly or fabricates a quote.

CONSTRAINTS:
- Apply the domain taxonomy in [DOMAIN_TAXONOMY] to normalize entity names, dates, and terminology.
- Apply the evidence sufficiency rules in [EVIDENCE_RULES] to determine what counts as adequate support.
- Do not alter claims that are fully supported by [CONTEXT].

OUTPUT:
Produce a valid JSON object matching this [OUTPUT_SCHEMA]:
{
  "audit_result": {
    "claims_reviewed": <integer>,
    "supported_claims": <integer>,
    "flagged_claims": [
      {
        "original_text": "<exact text from output>",
        "classification": "FABRICATED | UNSUPPORTED | MISATTRIBUTED",
        "evidence_gap": "<explanation of what is missing or contradictory>",
        "correction": "<corrected text or 'REMOVE' if no correction is possible>"
      }
    ]
  },
  "corrected_output": "<full regenerated response with only supported claims>"
}

If no claims are flagged, set flagged_claims to an empty array and set corrected_output to the original text.
If [CONTEXT] is insufficient to answer the original query at all, set corrected_output to the abstention message in [ABSTENTION_RULES].

[EXAMPLES]

--- CONTEXT ---
[CONTEXT]

--- ORIGINAL OUTPUT ---
[ORIGINAL_OUTPUT]

After pasting this template, the most critical adaptation step is defining your domain taxonomy and evidence rules. A medical domain might require ICD codes and peer-reviewed source thresholds; a legal domain might require case citations and jurisdiction checks; a financial domain might require GAAP references and filing dates. Inject these rules into the [DOMAIN_TAXONOMY] and [EVIDENCE_RULES] placeholders. The [EXAMPLES] placeholder should contain at least two few-shot demonstrations: one showing a hallucination being caught and corrected, and one showing a fully supported output passing audit. Without these examples, the model may default to generic fact-checking behavior that misses domain-specific failure patterns. Always wrap this prompt in a harness that validates the output JSON against [OUTPUT_SCHEMA] before accepting the corrected response, and escalate to human review if the retry budget is exhausted.

The Domain-Specific Fact Verification Prompt is designed to operate inside a structured validation harness, not as a standalone chat interaction. In production, this prompt typically runs after a primary generation step—such as a RAG answer, a clinical summary, or a legal clause extraction—and before the output reaches an end user or downstream system. The harness is responsible for providing the [DOMAIN_TAXONOMY], [EVIDENCE_SUFFICIENCY_RULES], and [TERMINOLOGY_CONSTRAINTS] that adapt the generic verification logic to your regulated domain. Without these injected parameters, the prompt will apply generic fact-checking heuristics that may miss domain-specific hallucination patterns like fabricated drug interactions, misattributed contract clauses, or invented regulatory citations.

Wire the prompt into your application as a post-generation verification step with a clear contract: the model receives the original output, the source context used to generate it, and the domain-specific rule set, then returns a structured verification report. Implement a JSON schema validator on the response to enforce the expected output shape—typically a list of claims, each with a verification status (SUPPORTED, UNSUPPORTED, INFERRED, CONTRADICTED), source mapping, and confidence score. If the validator rejects the response due to malformed JSON or missing required fields, use a structured output repair prompt from the Output Repair and Validation Prompts pillar before retrying verification. Log every verification result with the original output, source context, domain taxonomy version, and verification report for audit trails and hallucination trend analysis.

For high-stakes domains like healthcare, legal, or financial compliance, implement a human-in-the-loop gating mechanism. When the verification report flags any UNSUPPORTED or CONTRADICTED claims above a configurable severity threshold, route the output to a review queue rather than auto-publishing. The escalation payload should include the flagged claim, the source evidence the model checked, and the model's own explanation of why evidence was insufficient. This creates a feedback loop where reviewer decisions—confirm, correct, or escalate—can be captured and used to refine your [EVIDENCE_SUFFICIENCY_RULES] and domain taxonomy over time. Set a retry budget: if the verification prompt itself fails validation three times, escalate the entire output for human review rather than entering an infinite correction loop. Model choice matters here—use a model with strong instruction-following and structured output capabilities, and consider routing to a higher-capability model for verification of outputs generated by smaller, faster models.