Contract Clause Extraction with Citation Prompt Template

This prompt is built for legal engineering teams who need to extract specific, named clauses from contract documents with precise citation boundaries. The primary job-to-be-done is producing isolated clause text alongside section, page, and paragraph references plus confidence scores, so that downstream systems—obligation trackers, review queues, audit logs—can operate on traceable, verifiable outputs. The ideal user is a developer or legal operations engineer integrating this prompt into a document processing pipeline where every extracted clause must be attributable to a source location. Use this when your application requires structured clause objects that can survive a compliance review or feed into a contract lifecycle management system without manual re-verification of provenance.

This prompt assumes the input document has been pre-processed with page and paragraph markers. If your ingestion pipeline does not yet inject markers like [Page 4] or [Para 12] before the text reaches the model, the citation fields will be unreliable. The prompt works best on clean, machine-readable contract text—not heavily degraded OCR output, handwritten amendments, or image-only scans without a text layer. It expects a single document per request; multi-document comparison or cross-contract dependency resolution is out of scope and belongs in a separate workflow. The output schema includes a confidence field, which you should treat as a routing signal: high-confidence extractions can proceed automatically, while low-confidence results should be queued for human review before any downstream action is taken.

Do not use this prompt as a substitute for legal advice, and do not bypass human review for high-stakes decisions such as obligation enforcement, litigation hold triggers, or financial commitment tracking. The prompt is designed to reduce hallucination risk through citation discipline, but it cannot guarantee zero hallucination—especially when clause language is ambiguous, split across multiple sections, or referenced indirectly. Before deploying, run a targeted evaluation set that includes edge cases like clauses spanning page breaks, clauses embedded in schedules or exhibits, and documents where the target clause is absent. If your use case involves regulated filings, cross-border jurisdictional analysis, or real-time negotiation support, pair this extraction prompt with a human-in-the-loop approval step and log every extraction with its model version, input hash, and confidence score for auditability.

This prompt template is designed for legal engineering teams building contract review systems. It instructs the model to isolate a specific clause type from a contract, return the exact clause text, and provide a precise citation to the source location. The template uses square-bracket placeholders that you replace with your document content, target clause type, and extraction parameters before sending to the model. The output schema enforces structured JSON with citation boundaries, confidence scores, and explicit null handling for missing clauses.

textCopy
You are a legal document extraction assistant. Your task is to extract a specific clause from a contract and provide a precise citation to its location in the source document.

## INPUT
[CONTRACT_TEXT]

## TARGET CLAUSE
[CLAUSE_TYPE]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "clause_type": "string (the type of clause extracted)",
  "clause_text": "string (the exact text of the clause, verbatim from the source)",
  "citation": {
    "section_number": "string or null",
    "section_title": "string or null",
    "page_number": "integer or null",
    "paragraph_number": "integer or null",
    "line_range": "string or null (e.g., 'lines 12-18')"
  },
  "confidence": "number between 0.0 and 1.0",
  "is_present": "boolean",
  "absence_reason": "string or null (required if is_present is false)",
  "surrounding_context": "string (one sentence before and after the clause for verification)"
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Extract the clause text exactly as written. Do not paraphrase, summarize, or modify.
2. If the clause is not present, set is_present to false and provide a specific absence_reason.
3. If the clause is present but the citation is ambiguous, set confidence below 0.7 and note the ambiguity.
4. For multi-page documents, estimate page numbers based on the provided text if explicit page markers are absent, and note this in confidence.
5. If multiple clauses match the target type, extract the most specific or primary instance and note additional instances in a remarks field.
6. Do not invent clause text. If you are uncertain, reduce confidence and flag the uncertainty.

To adapt this template, replace [CONTRACT_TEXT] with the full text of the contract or the relevant section. Set [CLAUSE_TYPE] to the specific clause you need, such as "Indemnification," "Limitation of Liability," or "Governing Law." The [CONSTRAINTS] placeholder should contain any additional rules, such as jurisdiction-specific requirements, maximum clause length, or handling of amendments and addenda. The [EXAMPLES] placeholder should include one or two few-shot examples showing the expected output format for both present and absent clauses. For production use, always validate the output against the source document and implement a human review step for low-confidence extractions below 0.8.

Before deploying this prompt into a contract review pipeline, run it against a golden dataset of contracts with known clause locations. Measure citation boundary accuracy by checking whether the extracted text matches the exact source span. Track hallucination rate by flagging any clause text that does not appear verbatim in the source. For high-stakes workflows, combine this extraction prompt with a separate verification prompt that re-reads the cited location and confirms the extracted text matches.

The Contract Clause Extraction with Citation prompt is designed to be embedded in a multi-stage document processing pipeline, not called in isolation. The typical harness receives a pre-parsed document (with page, paragraph, and section metadata), identifies the target clause type from a user query or configuration, invokes the prompt with the relevant document chunk and extraction schema, validates the structured output, and routes low-confidence or failed extractions for human review. Because legal documents vary widely in structure and clause placement, the harness must handle cases where the clause is absent, split across pages, or embedded in a larger section with ambiguous boundaries.

Input preparation is the first critical step. Before calling the prompt, the harness must: (1) chunk the document into sections with preserved page and paragraph metadata; (2) identify candidate sections likely to contain the target clause type using keyword search, heading matching, or a lightweight classifier; (3) assemble the prompt context with the candidate text plus surrounding sections for boundary disambiguation. The [INPUT] placeholder should receive the pre-identified document text with inline citation markers (e.g., [Page 4, §2.1]). The [CLAUSE_TYPE] placeholder maps to a controlled taxonomy (e.g., indemnification, limitation_of_liability, governing_law). The [OUTPUT_SCHEMA] should be a JSON schema specifying fields like clause_text, citation_start, citation_end, confidence_score, and missing_fields. Never pass raw, unchunked PDF text directly to the prompt—layout misordering will corrupt citation boundaries.

Validation and retry logic must run after every prompt call. Parse the JSON output and validate: (1) citation boundaries exist within the provided input text (no hallucinated page numbers); (2) the extracted clause text matches the cited range (perform a substring check); (3) confidence scores are present and above a configurable threshold (typically 0.7 for auto-accept, 0.4–0.7 for review queue, below 0.4 for rejection); (4) required fields are populated or explicitly marked as null with a missing_reason. On validation failure, retry once with an error-specific instruction appended to the prompt (e.g., "The previous extraction cited page 7, but the input only contains pages 3–5. Re-extract using only the provided text."). After two failures, escalate to a human review queue with the original document, the failed extractions, and the validation errors logged. For high-risk clause types (indemnification, liability caps, termination rights), consider requiring human approval even on high-confidence extractions by default.

Model choice and tool integration affect reliability. Use a model with strong instruction-following and JSON mode support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Enable structured output mode if available to reduce parsing failures. For RAG-augmented pipelines, the retrieval step should supply the [INPUT] context, and the prompt's citation requirement acts as a grounding check—if the model cannot cite a source, it must not invent one. Log every extraction with: prompt version, model, input hash, output, validation result, retry count, and final disposition (accepted/reviewed/rejected). This audit trail is essential for legal engineering workflows where extraction decisions may be challenged. Avoid using this prompt with models under ~7B parameters without fine-tuning; smaller models frequently hallucinate citation boundaries and clause content.

Production hardening should include: a clause type router that selects the appropriate extraction schema before calling the prompt; a citation boundary overlap detector that flags when two extractions claim the same text for different clause types; and a missing clause classifier that distinguishes between "clause genuinely absent" and "clause present but extraction failed" using a secondary prompt or heuristic. The harness should never silently return an empty extraction—always surface the reason (absent, low confidence, parse failure, validation failure) to the calling system. When integrating with contract lifecycle management or compliance systems, map the extracted structured output to your system's canonical clause taxonomy and store the raw prompt response alongside the normalized record for future audit.