Legal Clause Quote Extraction Prompt

This prompt is designed for legal-tech engineers who need to extract precise, verbatim clause text from contracts in response to a legal query or claim. The primary job-to-be-done is grounding a downstream answer or analysis in an exact source span, making the extraction auditable and transparent. The ideal user is building a citation-aware application—such as a contract review tool, an obligation tracker, or a compliance checklist generator—where every output must be traceable to a specific section, clause, or defined term in the source document. The prompt assumes the input contract text is already parsed, cleaned of scanning artifacts where possible, and segmented into logical sections or clauses.

Use this prompt when you need strict text fidelity and section provenance. It handles nested clauses, cross-references, and defined terms by requiring the model to preserve the original wording and to cite the section path. This is not a summarization prompt; it is an extraction prompt. The output must be a verbatim quote, not a paraphrase. The harness should validate that the extracted text appears exactly in the source document and that the section provenance is correct. If your workflow can tolerate paraphrased answers or high-level summaries, this prompt is the wrong tool. Similarly, if the contract is a scanned image without reliable OCR, do not use this prompt until the text layer is verified—otherwise, extraction fidelity will degrade and validation will fail.

Before integrating this prompt into a product, define the failure modes you cannot accept. The most dangerous failure is a hallucinated quote that looks plausible but does not appear in the source. A secondary risk is extracting a clause that is factually present but irrelevant to the query, which can mislead downstream reasoning. Both failures require automated validation: exact string matching against the source, section-path verification, and a relevance check. In high-stakes legal workflows, always route extracted quotes for human review before they become part of a final answer, filing, or decision record. The prompt is a component in a larger grounding pipeline, not a standalone legal advisor.

This prompt template is the core instruction set for extracting verbatim legal clause text from contracts. It is designed to be copied directly into your prompt management system, IDE, or orchestration layer. Every variable is enclosed in square brackets so you can substitute your own inputs, schemas, and constraints without modifying the prompt's structural logic. The template handles nested clauses, cross-references, and defined terms, and it enforces exact text fidelity and section provenance.

textCopy
You are a legal clause extraction engine. Your task is to extract precise, verbatim clause text from the provided contract that matches the legal query or claim.

## INPUT
- Contract Text: [CONTRACT_TEXT]
- Legal Query or Claim: [QUERY]

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "extractions": [
    {
      "clause_text": "exact verbatim text from the contract",
      "section_reference": "section or article number",
      "clause_type": "category of the clause",
      "defined_terms_resolved": {
        "term_in_clause": "resolved definition"
      },
      "cross_references": ["list of referenced sections"],
      "relevance_rationale": "why this clause matches the query"
    }
  ],
  "query_coverage": "complete|partial|none",
  "missing_clauses_note": "explanation if expected clauses are absent"
}

## CONSTRAINTS
- Extract text verbatim; do not paraphrase or summarize.
- Preserve original punctuation, capitalization, and formatting.
- Resolve defined terms by locating their definitions within the contract.
- Follow cross-references to nested or related clauses and include them if relevant.
- If no clause matches, return an empty extractions array and set query_coverage to "none".
- Do not invent clauses or provide legal interpretation.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with your actual data and configuration. For [CONTRACT_TEXT], supply the full contract body as a string. For [QUERY], provide the legal question or claim you need evidence for. The [EXAMPLES] placeholder should contain one or two few-shot demonstrations showing correct extraction behavior, especially for nested clauses and defined term resolution. Set [RISK_LEVEL] to high to trigger additional validation steps in your harness, such as requiring human review before the output is used in any binding context. After substitution, test the prompt against a golden dataset of contracts with known clause locations to verify extraction accuracy and schema compliance.

Before deploying this prompt into a production pipeline, wire it into a validation harness that checks for exact text fidelity, section provenance, and schema adherence. For high-risk legal workflows, always route outputs through human review and log every extraction with the original contract hash and timestamp. Never use this prompt to generate legal advice or to replace qualified legal review.

The Legal Clause Quote Extraction Prompt is designed to operate as a stateless extraction function within a larger contract review pipeline. It should be called once per legal query against a single document or a pre-retrieved set of relevant clauses. Do not pass entire 200-page contracts in a single call; instead, use a retrieval step (keyword, semantic, or hybrid search) to surface candidate sections first, then invoke this prompt to extract precise clause text with provenance. The prompt expects a structured input containing the legal query, the full text of the candidate clause or section, and any defined terms or cross-reference context needed to resolve nested references.

Validation is mandatory before any extracted quote enters a downstream system. After the model returns its structured output, validate that: (1) the extracted quote text is a verbatim substring of the input document text (perform an exact string match or fuzzy match with a Levenshtein distance threshold ≤ 2 characters); (2) the section provenance fields (section number, title, paragraph) correspond to real locations in the source document; (3) defined terms used in the quote are resolved against the provided definitions map; and (4) cross-references cited in the reasoning field actually exist in the document. If validation fails, retry the prompt once with the validation error message appended to the [CONSTRAINTS] field. If the second attempt also fails, escalate to a human reviewer queue with the failed output, validation errors, and source document context attached.

Model choice and latency considerations: This prompt works well with GPT-4o, Claude 3.5 Sonnet, and other frontier models that demonstrate strong instruction-following for structured extraction. For high-volume contract review pipelines, consider using a smaller fine-tuned model (e.g., GPT-4o-mini or Claude Haiku) for the initial extraction pass, with a larger model reserved for validation-failure retries or high-risk clauses. Always log the full prompt, raw model output, validation results, and final accepted quote to an immutable audit store. Each record should include a unique extraction ID, document hash, timestamp, model version, and reviewer identity if human review was triggered. This audit trail is essential for legal-tech applications where extraction decisions may be challenged or reviewed later.

Tool integration and RAG considerations: If your application uses a retrieval-augmented generation (RAG) architecture, the retrieval step should surface clauses using a combination of dense embeddings (for semantic similarity to the legal query) and sparse keyword matching (for exact term matching on defined terms, section references, and statutory citations). Pass the top-k retrieved sections as the [INPUT] to this prompt, along with a definitions map extracted from the document's definitions section. Do not rely on the model to recall defined terms from memory; always provide them explicitly in the [CONTEXT] field. For cross-references that span multiple sections, implement a recursive extraction pattern: extract the primary clause, identify cross-referenced sections, retrieve those sections, and re-run the prompt with the expanded context.

Failure modes to monitor in production: The most common failure is partial extraction, where the model returns a truncated quote that omits dependent clauses or exceptions. Mitigate this by adding a post-extraction completeness check that verifies the quote includes all grammatically complete sentences surrounding the target clause. Another frequent failure is hallucinated section numbers when the model infers a section reference that does not exist in the source document. Always validate section provenance against the document's actual structure. Finally, watch for defined term confusion when a term is defined differently in multiple sections or schedules; the definitions map passed in [CONTEXT] must be scoped to the specific document part being analyzed. Set up monitoring alerts for validation failure rates exceeding 5% and for any extraction that passes validation but is later flagged by human review.