Legal Clause-Specific RAG Extraction Prompt

This prompt is built for a specific, high-stakes job: extracting and explaining a targeted legal clause from a set of pre-retrieved document chunks. The ideal user is a legal operations team, a contract manager, or a legal AI engineer who has already built a retrieval pipeline (RAG) over a contract repository. The user's core need is not to find the clause—the retrieval system has already done that—but to reliably transform the retrieved chunks into a structured, auditable output that a downstream system or human reviewer can immediately verify. The prompt is designed to produce four concrete artifacts: the verbatim clause text, a plain-language summary, a list of identified obligations, and cross-references to governing law sections. This structured output is meant to feed directly into a contract analysis dashboard, an obligation tracker, or a human review queue.

You should use this prompt when your RAG pipeline has already narrowed the search space to a set of relevant document sections and you need a deterministic, schema-conformant extraction. The prompt is particularly effective for common contract clauses like 'Limitation of Liability,' 'Indemnification,' 'Termination for Cause,' and 'Governing Law.' It is not a general-purpose contract Q&A bot, nor is it a substitute for legal advice. Do not use this prompt when the retrieval step is unreliable, when the document set is a single monolithic contract without chunking, or when the user's question is a broad, cross-document research task rather than a clause-specific extraction. For high-stakes decisions, such as those involving material financial exposure or litigation risk, the extracted output must be reviewed by a qualified human. The prompt includes explicit instructions to flag uncertainty, such as when a clause is referenced but its full text is not present in the retrieved chunks, which helps prevent silent failures.

Before implementing this prompt, ensure your upstream retrieval system is tuned for high recall over the specific clause types you care about. A common failure mode is feeding this prompt with chunks that are topically adjacent but do not contain the actual clause text, leading to a confident but incorrect extraction. To mitigate this, pair the prompt with a pre-processing step that validates chunk relevance, or use the prompt's built-in uncertainty flags to trigger a re-retrieval or human escalation. The next section provides the copy-ready prompt template, which you can adapt by replacing the square-bracket placeholders with your specific inputs, output schema, and constraints.

This template is the core instruction set for a legal clause extraction system. It is designed to be paired with a retrieval step that provides relevant contract sections as [RETRIEVED_CONTEXT]. The prompt forces the model to extract the exact clause text, produce a plain-language summary, identify active obligations, and cross-reference governing law sections. Before copying, replace every square-bracket placeholder with the actual values for your contract domain, jurisdiction, and risk tolerance.

codeCopy
You are a legal document analyst. Your task is to extract and explain a specific clause from a contract using only the provided context.

[RETRIEVED_CONTEXT]

[INPUT]

[OUTPUT_SCHEMA]
Respond strictly in JSON with the following structure:
{
  "clause_text": "The exact text of the identified clause.",
  "clause_type": "The standardized type of the clause (e.g., 'Limitation of Liability', 'Indemnification', 'Governing Law').",
  "plain_language_summary": "A one-paragraph summary in plain English suitable for a non-legal stakeholder.",
  "identified_obligations": [
    {
      "party": "The party bound by the obligation.",
      "action": "What the party must do or refrain from doing.",
      "trigger": "The event or condition that activates the obligation."
    }
  ],
  "governing_law_reference": "The specific section or jurisdiction cited for governing law, or null if none.",
  "confidence": "high|medium|low",
  "missing_information": ["List any critical details not found in the context that would be needed for a complete analysis."]
}

[CONSTRAINTS]
- Do not invent or infer clause text not present in [RETRIEVED_CONTEXT].
- If the requested clause type is not found, set 'clause_text' to null and 'confidence' to 'low', and explain in 'missing_information'.
- For 'confidence', use 'high' only if the clause is explicitly stated and unambiguous; use 'medium' if the language is present but subject to interpretation; use 'low' if the clause is implied or fragmented.
- The 'plain_language_summary' must not contain legal jargon.
- Flag any cross-referenced sections that are not provided in the context.

[RISK_LEVEL]
High. Outputs from this prompt may inform contract review and negotiation. All extractions must be verified by a qualified legal professional before use in decisions.

Adaptation Guidance: The most critical placeholder to customize is [OUTPUT_SCHEMA]. For a due-diligence workflow, you might add fields for risk_rating and negotiation_fallback. For an obligation-tracking system, you might flatten the output to a list of obligations with unique IDs. The [CONSTRAINTS] section should be tightened for your specific failure modes: if your retrieval often returns clauses from the wrong contract, add a constraint to verify the document title or date. Always keep the [RISK_LEVEL] warning and ensure your application layer enforces human review for any output used in a binding context.

Wiring this extraction prompt into an application requires treating each contract as a retrieval-and-extraction pipeline, not a single model call. The application layer must first chunk the agreement by section or clause boundary, embed those chunks, and retrieve the top-k passages relevant to the target clause type before invoking the prompt. The prompt itself expects retrieved context in [RETRIEVED_CLAUSES] and a structured output schema in [OUTPUT_SCHEMA], so the harness must assemble both from configuration—typically a clause-type registry that maps clause names (e.g., 'Limitation of Liability', 'Indemnification', 'Governing Law') to retrieval queries, expected output fields, and validation rules. For production use, run one extraction per clause type rather than batching unrelated clauses in a single request, which reduces the risk of cross-clause confusion and makes per-clause eval tractable.

Validation and retry logic are the most important parts of the harness. After the model returns JSON, validate it against the expected schema: required fields (clause_text, plain_language_summary, obligations, cross_references), field types, and non-empty constraints. If validation fails, retry with the same prompt but append the validation error message and the malformed output to a [PREVIOUS_ATTEMPT] placeholder in the retry call. Limit retries to two attempts; after the second failure, flag the clause for human review and log the full retrieval context, model response, and validation errors. For high-stakes contract types (indemnification, limitation of liability, termination rights), always route outputs to a human review queue regardless of validation success. The review interface should display the original clause text side-by-side with the extracted summary and obligations, letting reviewers accept, edit, or reject each extraction.

Model choice and latency budgeting shape the harness design. Clause extraction is a precision task where missing an obligation or misattributing a cross-reference carries real legal risk, so prefer a model with strong instruction-following and structured output reliability (e.g., GPT-4o, Claude 3.5 Sonnet) over smaller or faster models. Set a generous timeout (30–60 seconds per clause) and process clauses sequentially or with controlled concurrency to avoid rate-limiting. Log every extraction attempt—including the retrieval query used, the chunks retrieved, the model response, validation results, and the final human review decision—to build an audit trail and a golden dataset for regression testing. The most common production failure mode is retrieval returning the wrong clause variant (e.g., returning a 'Limitation of Liability' clause when the user asked for 'Indemnification'), so monitor retrieval precision separately from extraction quality and add a pre-extraction classification step if clause-type confusion exceeds 5% of requests.