Legal Document Review Prompting: Clause Extraction Without Hallucinated Citations

A lawyer at a nationally prominent firm used three different AI tools to draft a brief. CoCounsel, Westlaw Precision, and Google Gemini all contributed. All three fabricated citations. The Special Master struck every version and ordered $31,100 in fees.
That was Ellis George LLP and K&L Gates in 2025. They weren't amateurs. They used the "right" tools. The tools lied anyway.
Stanford's RegLab found that general-purpose LLMs hallucinate on legal queries 58-88% of the time. RAG-powered legal tools still hallucinate 17-33% of the time. Westlaw's AI-Assisted Research answered accurately on just 42% of queries in Stanford's testing. And 79% of lawyers now use AI in some capacity, according to the 2025 Clio Legal Trends Report.
The gap between adoption and competence is where sanctions live. The Damien Charlotin database now tracks over 1,200 court cases involving AI hallucinations. An attorney in Colorado was suspended. In March 2026 the Sixth Circuit fined two attorneys $15,000 each over fake and misrepresented citations in their appellate briefs.
Here's what actually works: structured prompting patterns that force the model to cite its sources from your document, not from its imagination.
The Core Problem With Legal AI Prompts
Most people prompt LLMs for legal work the same way they'd use a search engine. They paste a contract and ask "what are the key risks?" or "summarize the indemnification clause." The model happily generates confident, authoritative text. Some of it references real legal concepts. Some of it references cases that don't exist.
The failure mode isn't stupidity. It's fluency without grounding. LLMs are trained to produce plausible text, and legal language is especially susceptible because it follows predictable patterns. A fabricated citation to "Smith v. Johnson, 547 F.3d 812 (7th Cir. 2008)" looks exactly like a real one.
Contract review is different from legal research, though. When you're extracting clauses from a document sitting in your context window, you have a massive advantage: the source text is right there. Every technique in this post exploits that advantage.
Source-Grounding Directives
The simplest technique is also the most important. You explicitly tell the model where its information must come from and what to do when it can't find something.
You are a contract analyst. Review the following agreement and extract all indemnification clauses.
RULES:
- Base your analysis ONLY on the text provided below.
- For each clause you identify, quote the exact text from the document.
- Include the section number where each clause appears.
- If you cannot find a specific clause type, respond with "Not found in document."
- Do NOT reference any external legal standards, cases, or statutes.
- Do NOT infer terms that are not explicitly stated.
DOCUMENT:
[paste contract text here]
This works because it constrains the model's generation space. Without the grounding directive, the model will happily supplement your contract with "standard" indemnification language it learned during training. With it, the model treats the document as a closed-book exam.
The "Not found in document" instruction is critical. One of the simplest hallucination reduction techniques, per Microsoft's best practices for LLM deployment, is an explicit "If unsure, state I don't know" directive. Models that are told they can say "not found" actually do.
Structured Extraction With JSON Output
Free-text legal analysis is where hallucinations hide. When a model writes flowing paragraphs about contract terms, fabricated details blend with real ones. Structured output forces accountability.
Extract every obligation clause from the following contract. Return your analysis as a JSON array. Each object must contain exactly these fields:
{
"clause_id": "Sequential number",
"section_reference": "Exact section/paragraph number from the document",
"verbatim_text": "The exact quoted text of the clause, word for word",
"obligated_party": "Who bears the obligation",
"obligation_type": "One of: payment, performance, delivery, reporting, confidentiality, other",
"deadline": "Specific date or timeframe if stated, otherwise 'not specified'",
"risk_assessment": "low / medium / high with one-sentence reasoning",
"confidence": "high if clearly stated, medium if requires interpretation, low if ambiguous"
}
If a field's value is not explicitly stated in the document, use "not specified" -- do NOT infer or assume.
DOCUMENT:
[paste contract text here]
The verbatim_text field is the key innovation here. By requiring exact quotes, you create a built-in verification mechanism. You can search the original document for each quote. If the text doesn't appear, the model fabricated it.
The confidence field serves a different purpose. It flags clauses where the model is interpreting rather than extracting, which tells you where to focus your human review.
Expected output (partial):[ { "clause_id": "1", "section_reference": "Section 4.2(a)", "verbatim_text": "Contractor shall deliver all completed work product to Client within five (5) business days of the milestone date specified in Exhibit A.", "obligated_party": "Contractor", "obligation_type": "delivery", "deadline": "5 business days after milestone date per Exhibit A", "risk_assessment": "medium - deadline tied to external exhibit, verify Exhibit A dates are realistic", "confidence": "high" } ]
Chain-of-Verification for Ambiguous Clauses
Some clauses aren't straightforward extractions. Limitation of liability provisions, force majeure definitions, and IP assignment language often contain nested conditions and cross-references that require interpretation.
Chain-of-Verification (CoVe) uses a two-pass approach. First, the model extracts and interprets. Then it generates verification questions about its own analysis and answers them independently.
STEP 1: Read Section 7 (Limitation of Liability) of the contract below and summarize what it means in plain language. Quote the relevant text.
STEP 2: Now generate 3 verification questions that would confirm or challenge your interpretation. Focus on:
- Are there exceptions to the limitation that I might have missed?
- Does this clause cross-reference other sections that modify its scope?
- Is my plain-language summary accurate to the quoted text?
STEP 3: Answer each verification question by re-reading the relevant sections. If your original interpretation was wrong or incomplete, correct it.
DOCUMENT:
[paste contract text here]
This catches a specific failure mode: the model reads a liability cap of "$500,000" in Section 7.1 but misses that Section 7.3 carves out IP infringement claims from the cap entirely. The verification pass forces it to look again.
Playbook-Anchored Review
The strongest pattern for contract review in 2026 doesn't ask the AI to generate legal knowledge at all. It asks the AI to compare.
If your organization has standard contract terms, approved clause libraries, or negotiation playbooks, feed them as context alongside the contract under review.
You are comparing a vendor contract against our approved terms. Below are two documents:
DOCUMENT A: Our standard acceptable terms (the playbook)
DOCUMENT B: The vendor's proposed contract
For each section in Document B, determine:
1. Does it match our playbook terms? (match / partial match / deviation / not covered)
2. If there's a deviation, quote the specific language from BOTH documents.
3. Rate the business risk of each deviation: low / medium / high.
4. Suggest specific redline language that would bring Document B closer to our playbook.
Only compare terms that appear in both documents. If Document B contains clauses not covered by our playbook, list them separately under "Uncovered Terms" with the verbatim text.
PLAYBOOK:
[paste your standard terms]
VENDOR CONTRACT:
[paste the contract under review]
This works because you've eliminated the need for the model to "know" anything about law. It's doing text comparison, not legal reasoning. The hallucination surface drops dramatically when the model's job is "find differences between these two texts" rather than "tell me about standard indemnification practices."
Parameter Settings That Matter
Set temperature between 0.1 and 0.4 for legal extraction work. Higher temperatures increase randomness, which is the opposite of what you want when extracting specific contract language. Most API providers let you set this directly. If you're using a chat interface, look for "precise" or "factual" mode settings.
If your model supports it, set top_p to 0.9 or lower alongside low temperature. This further constrains token selection toward the most probable completions.
What These Techniques Don't Fix
No prompting pattern eliminates hallucination entirely. The Stanford research is clear on this: even the best RAG systems still hallucinate on 17% or more of legal queries.
These techniques reduce your risk, but they don't replace verification. The structured output formats make verification faster because you can spot-check quoted text against the source document. The playbook-anchored approach reduces risk further by keeping the model in "comparison mode" rather than "generation mode."
A California court in September 2025 declined to award attorneys' fees to opposing counsel who failed to detect AI-fabricated citations in the other side's filing. The implication: catching AI hallucinations may become everyone's responsibility, not just the person who used the tool.
The practical takeaway for anyone reviewing contracts with AI: always verify quoted text against the source, use structured output so you can verify efficiently, and never let an LLM be your only source of legal knowledge about what a clause "should" say.
Putting It Together
Start with source-grounding directives on every legal prompt. Add structured JSON output for clause extraction. Use chain-of-verification for complex or ambiguous provisions. Anchor to your own playbook whenever possible.
A freelancer or small business owner who applies these four patterns will produce more reliable AI-assisted contract analysis than the lawyers who got sanctioned for trusting three different legal AI tools without verification.
That's not a knock on lawyers. It's a statement about prompting discipline.
If your team handles contract review and wants to build reliable AI prompting workflows, Kief Studio runs hands-on training sessions that cover these techniques and more. Join the conversation on Discord or reach out to set something up.
Rather have someone set it up for you?
That's a fair call. LTFI, the agentic business operating system from Kief Studio, can set up the work these guides describe and run it with you. No website yet? Kief Studio will build you one for free.

