Legal Claim Extraction Prompt Template

This prompt is designed for legal tech product teams who need to decompose complex legal documents into a structured set of discrete, verifiable factual assertions. The primary job-to-be-done is to transform unstructured text from contracts, pleadings, deposition transcripts, or regulatory filings into atomic claim records that a downstream verification engine, evidence-matching service, or human review queue can consume. The ideal user is an engineering lead or AI architect building a litigation support, contract review, or compliance automation product. They have the source documents and need a reliable, schema-consistent extraction step that preserves original language and provides precise source citations, not a summary or a risk score.

Use this prompt when the goal is to create a structured, machine-readable claim inventory from a single legal document. It is appropriate when you need to force the model to identify claim boundaries, extract the exact text of an assertion, and cite its location by section, paragraph, or page. The prompt is engineered to flag materiality and separate factual claims from legal arguments, prayers for relief, or rhetorical statements. This makes it a critical early step in a verification pipeline, positioned before evidence retrieval, claim-to-source matching, or contradiction detection. It is not a replacement for legal advice, clause interpretation, or risk assessment, and it should not be used as a standalone tool without a defined downstream consumer for the extracted claims.

Do not use this prompt when the task requires interpreting the legal effect of a clause, predicting case outcomes, or providing a subjective risk score. It is also unsuitable for multi-document cross-referencing in a single pass; for that, you should extract claims from each document individually and then use a separate evidence-matching prompt. The prompt assumes the input is a clean, machine-readable text. If you are working with scanned PDFs or poor OCR output, you must preprocess the document with a document intelligence pipeline to correct text and identify structural elements before extraction. Finally, because the output is a structured claim record that may be used in high-stakes legal contexts, you must implement a validation layer and a human-in-the-loop review step for any claims flagged as material or used in a formal proceeding.

This prompt template is designed to be dropped directly into your legal document review pipeline. It instructs the model to decompose a provided legal text into atomic, self-contained claims, each anchored to its exact source location. The template uses square-bracket placeholders that you must replace with actual values before sending the request to the model. The core instruction set enforces claim atomicity, context preservation, and a strict output schema, which are the foundational requirements for any downstream verification or contract review task.

textCopy
You are a precise legal claim extraction engine.
Your task is to read the provided legal document text and extract every discrete, verifiable factual assertion it contains.

Follow these rules strictly:
1.  **Atomicity:** Each extracted claim must contain exactly one factual assertion. Do not combine multiple facts into a single claim.
2.  **Verbatim Anchoring:** For each claim, you must provide the exact, verbatim source text from the document that supports it. This is the [SOURCE_CITATION].
3.  **Context Preservation:** The claim must be understandable on its own without reading the rest of the document. Expand pronouns and resolve implicit references where necessary, but do not alter the original meaning.
4.  **Materiality Flagging:** Classify each claim as `MATERIAL`, `IMMATERIAL`, or `CONTEXTUAL_DEPENDENT` based on its potential impact on the core subject matter of the document (e.g., a contract's primary obligations, a filing's key disclosures).
5.  **Exclusion:** Do not extract rhetorical questions, section headings, or purely procedural language (e.g., "This agreement is dated as of...") as claims.

[INPUT]
### LEGAL DOCUMENT TEXT:
[DOCUMENT_TEXT]

[OUTPUT_SCHEMA]
You must output a single JSON object with a key "claims" that contains an array of claim objects.
Each claim object must have the following keys:
- "claim_id": A unique string identifier for the claim (e.g., "CL-001").
- "claim_text": The extracted, self-contained factual assertion.
- "source_citation": The exact verbatim text from the document.
- "source_location": A description of where the citation is found (e.g., "Section 2.1, paragraph 3").
- "materiality": One of "MATERIAL", "IMMATERIAL", or "CONTEXTUAL_DEPENDENT".
- "subject_matter": A short topic label for the claim (e.g., "Payment Obligation", "Termination Right").

[CONSTRAINTS]
- If no factual claims are found, return an empty "claims" array.
- Do not include any text outside the JSON object.
- Ensure the JSON is valid and parseable.

To adapt this template, start by replacing [DOCUMENT_TEXT] with the full text of the legal document you are analyzing. The [OUTPUT_SCHEMA] is a critical contract for your application parser; you can extend it with domain-specific fields like governing_law or risk_score as needed. The [CONSTRAINTS] section is your primary defense against malformed outputs and should be reinforced with a post-processing validation step. For high-stakes workflows, always route claims flagged as MATERIAL or CONTEXTUAL_DEPENDENT for human attorney review before they are used in any downstream system or analysis.

Integrating the Legal Claim Extraction prompt into a production legal tech application requires more than a single API call. The prompt must be wrapped in a harness that validates structural output, enforces claim atomicity, preserves source citations, and routes ambiguous or high-risk extractions for human review. This section outlines a practical implementation pattern for contract review, litigation support, or compliance scanning tools where extraction errors can cascade into downstream analysis failures.

Validation layer. After the model returns a JSON array of claims, apply a structural validator before any claim enters your database or review queue. Each claim object must contain non-empty claim_text, source_citation (with document_id, section, and excerpt fields), and materiality enum values. Reject or repair records where claim_text exceeds a single verifiable assertion—compound claims should be split by a secondary decomposition prompt. Validate that source_citation.excerpt is a verbatim substring of the source document using a string-matching check; flag mismatches for human review. Retry logic. If the model returns malformed JSON, missing required fields, or an empty claims array when the source document contains substantive content, implement a single retry with the same prompt plus the validation error message appended as a [PREVIOUS_ERROR] context block. After one retry, escalate to a human review queue rather than looping indefinitely. Confidence thresholds. Use the model's confidence score (0.0-1.0) to route claims: claims above 0.85 can auto-ingest with logging; claims between 0.5 and 0.85 should surface in a review interface with the source excerpt highlighted; claims below 0.5 should be held for mandatory human review with a warning that the extraction may be unreliable.

Human review routing. Build a review queue that presents each flagged claim alongside its source document context, the model's extracted text, and the confidence score. Reviewers should be able to accept, edit, reject, or split claims. Capture reviewer actions as training signals for future fine-tuning or prompt refinement. Model choice. For legal claim extraction, prefer models with strong instruction-following and structured output capabilities. GPT-4o and Claude 3.5 Sonnet perform well on this task; avoid smaller models that struggle with precise citation boundaries. If processing sensitive legal documents, deploy a private instance or use an API with a zero-data-retention policy. Logging and audit. Log every extraction request with the prompt version, model identifier, input document hash, output claims, validation results, retry count, and final routing decision. This audit trail is essential for legal tech products where extraction decisions may be challenged in review or litigation contexts.

What to avoid. Do not treat the prompt output as ground truth without validation. Do not skip the verbatim excerpt check—paraphrased citations are a leading cause of undetected extraction errors. Do not auto-ingest low-confidence claims into downstream workflows without review. Do not use the same prompt for both extraction and verification; extraction identifies what was claimed, while verification checks whether the claim is supported by evidence. Keep these pipelines separate. Next steps. Once the extraction harness is stable, integrate it with a claim verification prompt from the Fact Checking and Claims Verification pillar to close the loop from extraction to evidence matching.