Evidence Requirement

An evidence requirement functions as an absolute rule within a system prompt. It explicitly instructs the model: "For every factual claim you make, you must cite the specific sentence, paragraph, or data point from the provided context that supports it." This shifts the model's priority from fluent generation to verifiable extraction. Instead of synthesizing from its internal knowledge (which can be outdated or incorrect), the model is forced to operate as a deterministic retrieval engine, tethering its output directly to the source material. The instruction often specifies a format, such as using inline brackets [Doc1, para 3] or footnotes, to make the evidence trail explicit and easily verifiable by a downstream system or human reviewer.

Evidence requirements are often enforced by coupling them with structured output formats. The prompt can mandate a response schema where each claim is paired with its source.

Example Instruction: "Output your answer as a JSON array. Each object must have two keys: 'claim' and 'evidence'. The 'evidence' value must be a direct quote from the provided documents."

This technical constraint makes non-compliance structurally impossible for the model, as generating invalid JSON would break the response. It transforms the task from open-ended generation into a structured information extraction problem, dramatically reducing the model's latitude to hallucinate. This pattern is critical for building reliable, automated pipelines where outputs must be programmatically validated.

Evidence requirements are the logical endpoint of a Retrieval-Augmented Generation (RAG) pipeline. In a RAG system, a retrieval step fetches relevant context from a knowledge base. The evidence requirement prompt then acts as a strict grounding layer, ensuring the generation phase does not deviate from that retrieved context.

• Without Evidence Requirement: The model may use retrieved documents as inspiration but supplement with its own knowledge, leading to a blend of correct and fabricated info.
• With Evidence Requirement: The model is constrained to be a paraphraser and synthesizer of only the provided chunks. This closes the hallucination loop, making the system's accuracy directly dependent on retrieval quality. It provides a clear audit trail: if a claim is wrong, you can check if the cited source is wrong or if the model misinterpreted it.

Advanced implementations add a self-verification step triggered by the evidence requirement. After generating an initial response with citations, the model receives a follow-up instruction: "Review each of your cited claims. Confirm the quote in the 'evidence' field directly and unambiguously supports the claim in the 'claim' field. If any do not, rewrite the claim to be accurate or state 'Insufficient evidence.'"

This creates a simple fact-checking loop within the model's single inference pass. It mitigates a common failure mode where a model cites a nearby but irrelevant source. By forcing a second-pass review specifically for claim-evidence alignment, the system's factual fidelity is significantly improved. This is a key technique for high-stakes domains like legal document analysis or medical summarization.

A robust evidence requirement must also define the model's behavior when evidence is not found. The prompt must include a fallback instruction to prevent the model from fabricating a source.

Critical Instructions:

• "If the context does not contain information necessary to answer the question, state 'The provided context does not contain evidence to support an answer.'"
• "Do not infer answers from general knowledge if they are not in the context."
• "Express uncertainty explicitly when evidence is partial or ambiguous."

This transforms a lack of knowledge from a hidden risk (potential hallucination) into an explicit, manageable output. It aligns the model's behavior with uncertainty acknowledgment protocols, which is essential for building trustworthy AI systems. The system's reliability becomes measurable: its rate of "I don't know" responses is a key performance indicator.

While powerful, evidence requirements have specific limitations that engineers must design around:

• Garbage In, Garbage Out: If the retrieved context is wrong, the model will cite wrong evidence with high confidence. The requirement ensures fidelity to context, not to truth.
• Over-Citation: Models may become overly conservative, citing evidence for trivial or self-evident statements, reducing clarity.
• Context Window Limits: In long documents, the model may struggle to locate and cite the most precise evidence if the relevant text is far from the query in the context window.
• Misinterpretation of Evidence: The model may correctly cite a source but then misinterpret or over-extrapolate from it in the claim. The self-verification step is designed to catch this.
• Adversarial Prompts: A user may embed a false statement within the context and then ask a question leading to it; the model will faithfully cite the false evidence. This requires additional contradiction detection logic across source documents.

Used to generate executive briefings, competitive intelligence reports, and market analyses where every claim must be traceable to internal documents, earnings reports, or verified data feeds. This prevents the model from confabulating financial figures or strategic details.

• Example: "Synthesize a competitor analysis from the provided 10-K filings. For each strength or weakness you list, cite the exact page and paragraph from the source document."

Critical for automating the extraction of obligations, clauses, and liabilities from legal texts. The evidence requirement forces the model to output specific verbatim excerpts or precise references (e.g., 'Section 4.2(c)'), eliminating the risk of misinterpretation or invented terms.

• Example: "List all termination-for-cause clauses in the provided MSA. For each clause, provide the exact wording and its section number."

Supports researchers by summarizing papers or generating literature reviews with strict source attribution. This ensures that hypotheses, results, and conclusions are correctly attributed to the original authors, preventing plagiarism and citation hallucination.

• Example: "Compare the methodologies of the three provided studies on transformer efficiency. For each comparison point, cite the author, year, and page number where the method is described."

In healthcare applications, evidence requirements are paramount. When summarizing patient records or medical guidelines, the model must link every recommendation or observation to a specific lab value, clinician note, or peer-reviewed source. This enforces factual fidelity and auditability.

• Example: "Based on the provided patient history and lab results, list potential diagnoses. Next to each, quote the clinical finding from the records that supports it."

Used to automate the initial stages of fact-checking by requiring models to cross-reference claims against a provided corpus of trusted sources (e.g., press releases, official statements, databases). The output is a structured list of claims with supporting or contradicting evidence citations.

• Example: "Verify the following five statements about the event using the provided press kit and transcripts. For each, state 'Supported' or 'Contradicted' and provide the relevant quote."

Ensures that support agent assistants or automated responders base their answers solely on the latest product documentation, knowledge base articles, or policy manuals. This creates a verifiable audit trail, proving that advice was grounded in official sources, which is crucial for regulatory compliance and liability protection.

• Example: "Answer the customer's query about service SLAs. Your entire response must be derived from the 'Q3 Service Guide.pdf'. Include the guide's section title for each piece of information you use."

A grounding prompt is a foundational instruction that explicitly requires a language model to base its entire response on provided source material, verifiable facts, or a specific knowledge base. It establishes the rule that the model must not extrapolate beyond the given context.

• Mechanism: Acts as a high-level constraint, often phrased as "Base your answer solely on the following text."
• Relationship to Evidence Requirement: An Evidence Requirement is a specific, enforceable implementation of a grounding prompt, mandating point-by-point citations.

A source attribution instruction dictates the format and granularity of citations. While an Evidence Requirement states that evidence is needed, this term specifies how to present it.

• Examples: "Cite using [Document A, Page 3]" or "Provide inline hyperlinks to the source paragraphs."
• Key Function: Ensures the provided evidence is actionable and verifiable by a human or automated system, turning a general requirement into a structured output.

The no fabrication rule is an absolute, non-negotiable prohibition within a prompt. It is the most direct guardrail against hallucination.

• Typical Wording: "Do not invent any details, quotes, data, or citations not present in the provided context. If the information is not present, state 'Not provided in context.'"
• Contrast with Evidence Requirement: An Evidence Requirement proactively elicits support, while the No Fabrication Rule is a reactive veto on unsupported content. They are often used together for defense-in-depth.

A fact-checking loop is a multi-step prompt architecture that separates generation from verification. It instructs the model to act as its own critic in discrete phases.

• Common Pattern:
  1. Generate an initial answer.
  2. Critique the answer against the source, listing unsupported claims.
  3. Revise the answer to address the critique.
• Relationship: An Evidence Requirement can be embedded within a fact-checking loop as the criterion for the critique phase, providing a clear standard for what constitutes a supported claim.

Structured verification is a prompt pattern that forces the model to output its fact-checking process in a predefined, machine-readable format. It makes the verification step explicit and auditable.

• Output Format: Often a table or JSON object with fields like Claim, Supporting_Evidence, Source_Location, and Verification_Status.
• Advantage: Transforms the Evidence Requirement from a narrative instruction into a deterministic schema, reducing ambiguity and enabling automated validation of the model's own compliance.

A retrieval-augmented prompt explicitly integrates content fetched from an external knowledge system (like a vector database) into the model's context window. The Evidence Requirement is then applied to that retrieved context.

• Workflow:
  1. User query triggers a semantic search.
  2. Top-ranked document snippets are injected into the prompt.
  3. The prompt includes an instruction like: "Using ONLY the retrieved documents below, answer the question. For each key point, cite the relevant snippet."
• Synergy: This provides the raw material (retrieved context) to which the Evidence Requirement (the citation rule) is applied, forming the core of a Retrieval-Augmented Generation (RAG) system.