Legal Clause Extraction from Contract Text Prompt Template

This prompt is designed for legal tech platform teams who need to convert unstructured contract narratives into structured, machine-readable clause records. The primary job-to-be-done is extracting specific clause types, obligations, effective dates, and associated risk flags from full-text contracts, while preserving a direct citation back to the source text. The ideal user is an integration engineer or backend developer building a contract review pipeline, where the model's output must be ingested by a downstream database, search index, or review queue without manual reformatting.

Use this prompt when you have already attempted direct structured output generation (e.g., JSON mode or function calling) and the model has failed, producing a narrative or semi-structured markdown response instead. This is a repair and conversion playbook, not a first-pass extraction strategy. It assumes the input is a raw model response containing identified clauses in prose form. The prompt requires a defined [OUTPUT_SCHEMA] with typed fields, a [CLAUSE_TAXONOMY] listing the clause types to detect, and the original [CONTRACT_TEXT] for source grounding. Do not use this prompt for initial contract review, legal advice generation, or any workflow where the model is the first and only reader of the contract. It is a post-generation normalization step.

Before deploying, you must pair this prompt with a validation harness that checks for clause boundary accuracy, missing clause detection, and hallucinated citations. The output should never flow directly to an end-user or a system of record without automated schema validation and, for high-risk contracts, a human review step. If the contract domain is highly regulated (e.g., securities filings, healthcare BAAs), the pipeline must log every extraction with its source citation and confidence flag for auditability. The next section provides the copy-ready prompt template you can adapt to your specific taxonomy and output schema.

This prompt template is designed to convert unstructured contract text into a structured JSON array of clause records. Each record includes the clause type, extracted text, obligations, dates, risk flags, and source citations. The template uses square-bracket placeholders that you must replace with your actual contract text, target clause types, output schema, and risk definitions before use. The prompt enforces source grounding by requiring verbatim text extraction and citation to specific sections, which is essential for legal workflows where traceability is non-negotiable.

textCopy
You are a legal document analyzer. Your task is to extract specific clause types from the provided contract text and return them as structured JSON records.

## INPUT
Contract Text:
[CONTRACT_TEXT]

## TARGET CLAUSE TYPES
Extract only the following clause types if present:
[CLAUSE_TYPES]

## OUTPUT SCHEMA
Return a JSON object with a single key "clauses" containing an array of clause objects. Each clause object must have these fields:
- "clause_type": string (one of the target clause types)
- "clause_text": string (verbatim text from the contract, exactly as written)
- "source_location": string (section number, paragraph reference, or line range where this clause appears)
- "obligations": array of strings (specific duties, requirements, or commitments identified in this clause)
- "effective_date": string or null (ISO 8601 date if a specific date is mentioned, otherwise null)
- "expiration_date": string or null (ISO 8601 date if a specific date is mentioned, otherwise null)
- "risk_flags": array of strings (select from: [RISK_CATEGORIES])
- "risk_rationale": string (brief explanation of why each risk flag applies, citing specific language)
- "counterparty": string or null (name of the other party if identifiable, otherwise null)

## CONSTRAINTS
1. Only extract clauses that match the target clause types listed above.
2. Extract clause_text verbatim from the contract. Do not paraphrase or summarize.
3. If a clause type is not present in the contract, do not include it in the output.
4. For dates, use ISO 8601 format (YYYY-MM-DD). If a date is ambiguous or partial, set the field to null and note the ambiguity in risk_rationale.
5. Risk flags must only come from the provided risk categories list. Do not invent new categories.
6. If no risk flags apply, use an empty array.
7. If you cannot determine a field value with confidence, use null rather than guessing.
8. Do not include any text outside the JSON object.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
This is a [RISK_LEVEL] extraction task. [HUMAN_REVIEW_INSTRUCTION]

To adapt this template, replace each square-bracket placeholder with your actual values. For [CONTRACT_TEXT], insert the full contract text. For [CLAUSE_TYPES], provide a comma-separated list such as "Indemnification, Limitation of Liability, Termination, Confidentiality, Payment Terms." For [RISK_CATEGORIES], define your risk taxonomy like "Uncapped Liability, One-Sided Termination, Automatic Renewal, Vague Obligation, Missing Deadline." The [FEW_SHOT_EXAMPLES] placeholder should contain one or two example input-output pairs showing correct extraction behavior, which dramatically improves accuracy for legal text. The [RISK_LEVEL] and [HUMAN_REVIEW_INSTRUCTION] placeholders let you adjust the review requirement based on your use case—for high-stakes contract review, set [RISK_LEVEL] to "high" and [HUMAN_REVIEW_INSTRUCTION] to "All extracted clauses must be reviewed by a qualified legal professional before use." For lower-risk internal triage, you might set it to "medium" with a lighter review instruction. After adapting the template, test it against a golden dataset of contracts with known clause locations and types to measure extraction recall, clause boundary accuracy, and risk flag precision before deploying to production.

The legal clause extraction prompt is designed to be called from an application layer that manages document chunking, prompt assembly, and output validation. The typical integration pattern involves splitting a contract into sections or pages, sending each chunk through the prompt, and then merging the extracted clause records into a unified result set. Because legal workflows carry compliance risk, the harness must enforce strict validation before any extracted clause reaches a database or user interface. The prompt itself is stateless—it receives one chunk of contract text and returns structured clause records—so the application is responsible for deduplication, cross-chunk clause merging, and maintaining source text provenance across the entire document.

A production harness should implement a validate-or-repair loop around each prompt call. After receiving the model's JSON response, validate that every clause record contains the required fields: clause_type, clause_text, source_citation, obligations, effective_date, and risk_flags. If validation fails, use a repair prompt from the Output Repair and Validation pillar to fix malformed JSON, missing fields, or type errors before retrying. Set a maximum of two repair attempts per chunk; if the output still fails validation, flag the chunk for human review and log the raw model response for debugging. For model choice, use a model with strong structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) and enable structured output mode or JSON mode with a provided schema to reduce format failures at the source. Temperature should be set to 0 or near-zero to maximize extraction consistency across chunks.

Human review gates are essential for high-risk clause types. Configure the harness to automatically escalate any extracted clause where risk_flags contains values like indemnification, limitation_of_liability, termination_rights, or uncapped_liability. These records should enter a review queue before being committed to the clause repository. Additionally, implement a missing clause detector that compares the set of expected clause types for the contract category against what was actually extracted. If a contract is expected to contain a governing law clause but none was found, flag the document for manual review rather than silently accepting the gap. Log every extraction with the model version, prompt version, chunk identifier, validation result, and review decision to maintain an audit trail for compliance purposes.

For performance and cost management, batch chunks efficiently but avoid sending chunks larger than the model's reliable context window for structured extraction (typically 4,000-8,000 tokens per chunk works well). Implement caching for repeated contract sections or standard boilerplate language to reduce redundant API calls. If processing high volumes of contracts, consider a two-stage pipeline: first use a cheaper, faster model to identify which chunks contain clauses of interest, then route only those chunks through the full extraction prompt. This reduces cost while maintaining accuracy on the sections that matter. Finally, build a regression test suite using a golden dataset of annotated contracts with known clause types, obligations, and risk flags. Run this suite against any prompt or model change before deploying to production, and monitor extraction accuracy drift over time using the evaluation rubrics defined in the LLM Judge and Evaluation pillar.