Entity Extraction Prompt for Legal Contracts

This prompt is designed for legal operations teams and contract intelligence engineers who need to extract structured entity records from contract text. It targets parties, dates, jurisdictions, governing law, and defined terms while handling counterparty aliases, amendment chains, and entity roles such as licensor, lessee, or indemnitor.

Use this prompt when you need to ingest a corpus of agreements into a contract management system, populate a clause library, or feed a downstream risk analysis pipeline. The prompt assumes the input is clean, machine-readable contract text. It does not handle scanned PDFs or handwritten markups without an OCR preprocessing step.

This is not a contract review or redlining prompt. It does not flag risky clauses, suggest alternative language, or provide legal advice. Its job is extraction, not interpretation. For high-risk workflows, always route low-confidence extractions to a human review queue and maintain source attribution for every extracted entity.

This prompt template is designed to be dropped into your AI system for extracting parties, dates, jurisdictions, governing law, and defined terms from contract text. It instructs the model to produce a predictable JSON structure that downstream systems can ingest without parsing surprises. The template uses square-bracket placeholders that you must replace with your specific contract text, entity definitions, and output requirements before sending to the model.

textCopy
You are a legal entity extraction system. Your task is to extract structured entities from the provided contract text. You must follow the output schema exactly. Do not add fields, omit required fields, or change field types. If an entity type is not present in the text, return an empty array for that field. If an entity is present but ambiguous, include it with a confidence score below 0.8 and a flag for human review.

## INPUT
[CONTRACT_TEXT]

## ENTITY DEFINITIONS
Extract the following entity types:
- parties: Legal persons or organizations entering into the contract. Include their role (e.g., licensor, lessee, indemnitor, counterparty).
- effective_date: The date the contract becomes effective. Normalize to YYYY-MM-DD format.
- termination_date: The date the contract terminates or expires. Normalize to YYYY-MM-DD format. If not specified, use null.
- governing_law: The jurisdiction whose laws govern the contract. Include the specific state or country.
- jurisdiction: The courts or venue where disputes will be resolved.
- defined_terms: Terms explicitly defined in the contract. Include the term and its definition.
- amendment_references: References to prior agreements, amendments, or related contracts.
- monetary_amounts: All monetary figures with their currency, amount, and what they represent (e.g., license fee, damages cap, retainer).

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "contract_id": "string or null if not provided",
  "extraction_timestamp": "ISO 8601 timestamp of extraction",
  "entities": {
    "parties": [
      {
        "name": "string",
        "role": "string",
        "aliases": ["string"],
        "confidence": 0.0,
        "source_span": "exact text from contract",
        "needs_review": false
      }
    ],
    "effective_date": {
      "value": "YYYY-MM-DD or null",
      "confidence": 0.0,
      "source_span": "exact text from contract",
      "needs_review": false
    },
    "termination_date": {
      "value": "YYYY-MM-DD or null",
      "confidence": 0.0,
      "source_span": "exact text from contract",
      "needs_review": false
    },
    "governing_law": {
      "jurisdiction": "string or null",
      "confidence": 0.0,
      "source_span": "exact text from contract",
      "needs_review": false
    },
    "jurisdiction": {
      "venue": "string or null",
      "confidence": 0.0,
      "source_span": "exact text from contract",
      "needs_review": false
    },
    "defined_terms": [
      {
        "term": "string",
        "definition": "string",
        "confidence": 0.0,
        "source_span": "exact text from contract",
        "needs_review": false
      }
    ],
    "amendment_references": [
      {
        "reference": "string",
        "date": "YYYY-MM-DD or null",
        "relationship": "string (e.g., amends, supersedes, incorporates)",
        "confidence": 0.0,
        "source_span": "exact text from contract",
        "needs_review": false
      }
    ],
    "monetary_amounts": [
      {
        "amount": 0.0,
        "currency": "string (ISO 4217 code)",
        "description": "string",
        "confidence": 0.0,
        "source_span": "exact text from contract",
        "needs_review": false
      }
    ]
  }
}

## CONSTRAINTS
- Every entity must include a source_span: the exact text from the contract that supports the extraction.
- Confidence scores must be between 0.0 and 1.0. Use 0.0 only when the entity type is not present in the text.
- Set needs_review to true when confidence is below 0.8, when the source text is ambiguous, or when multiple interpretations are possible.
- For parties, resolve aliases and include them in the aliases array. Use the canonical legal name as the name field.
- For dates, normalize to YYYY-MM-DD. If only a partial date is available (e.g., only the year), use the available portion and set needs_review to true.
- If the contract references amendments or prior agreements, extract them as amendment_references even if the full text of those documents is not provided.
- Do not hallucinate entities. If an entity type is not present, return an empty array or null as specified in the schema.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this prompt, replace [CONTRACT_TEXT] with the full text of the contract you are processing. If you have few-shot examples that demonstrate correct extraction for your specific contract types, add them to the [EXAMPLES] section. Set [RISK_LEVEL] to 'high' if the extraction will be used for binding decisions without human review; this instructs the model to be more conservative with confidence scores and to flag more entities for review. For production deployments, always validate the output JSON against the schema before ingestion, and route any entity with needs_review set to true to a human review queue. This prompt works best with models that have strong instruction-following and JSON generation capabilities, such as GPT-4, Claude 3.5 Sonnet, or fine-tuned variants. Avoid using this prompt with models that have weak schema adherence, as missing or malformed fields will break downstream ingestion pipelines.

This prompt is designed to be called as a single step within a larger contract ingestion pipeline, not as a standalone chat interface. The application layer is responsible for document chunking, prompt assembly, output validation, and downstream routing. Because legal contracts carry high operational and regulatory risk, the harness must enforce strict schema compliance, log every extraction attempt, and escalate ambiguous outputs to a human review queue before extracted entities reach a contract management system or obligation tracker.

Pre-processing: Split the contract into sections (parties, recitals, definitions, operative clauses, signatures) using a layout-aware parser or section-heading heuristic. Each section becomes a separate prompt call with shared context about the document type and governing jurisdiction. Pass the full contract text as a single [DOCUMENT] block only for short agreements under ~8,000 tokens; for longer contracts, extract the parties clause, definitions section, and signature block as targeted chunks and merge results in the application layer. Model choice: Use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and enable JSON mode or structured outputs with the schema defined in the prompt. Do not use a smaller, faster model for this workflow unless you have a validated fine-tuned variant and a high-recall validation layer. Validation: After each extraction call, validate the JSON output against the expected schema. Check that: (1) all required entity categories are present, even if empty arrays; (2) every entity has a non-empty mention_text and canonical_form; (3) confidence values are numbers between 0 and 1; (4) source_span references exist in the input text; (5) dates parse to valid ISO 8601 strings. Reject and retry any output that fails schema validation, up to two retries with the validation errors appended to the prompt as [PREVIOUS_ERRORS].

Retry and escalation logic: If the model fails to produce valid JSON after two retries, or if any extracted entity has a confidence score below your defined threshold (start at 0.7 for high-risk fields like party names and governing law, 0.5 for defined terms), flag the entire contract section for human review. Do not silently drop low-confidence entities—route them to a review queue with the source text, the model's partial output, and the validation failure details. Logging: Log every extraction call with: prompt version, model identifier, input token count, output token count, latency, validation pass/fail, retry count, and the final output or escalation reason. This audit trail is essential for legal operations teams who must demonstrate extraction quality to compliance reviewers. Downstream ingestion: Only after validation passes should extracted entities be written to the contract management system. Map the canonical entity forms to your master data records using the entity resolution prompts in this pillar. Store the raw extraction output alongside the mapped records so that auditors can trace every system field back to its source span in the original contract.

What to avoid: Do not use this prompt in a streaming or real-time chat context where partial outputs might be consumed before validation. Do not skip the source-span validation step—legal teams need to click from an extracted party name directly to the contract text that produced it. Do not assume the model will correctly handle amendment chains or counterparty aliases without explicit instructions; those cases are covered in the prompt template's [CONSTRAINTS] section and should be tested with your own contract corpus before production deployment. Start with a golden dataset of 20–50 annotated contracts covering your most common agreement types, run the full pipeline, and measure precision and recall per entity category before expanding to live documents.