Insurance and Risk Allocation Clause Extraction Prompt

This prompt is designed for risk management and compliance engineers who need to extract structured insurance and risk allocation data from contracts at scale. The job-to-be-done is isolating specific provisions—required insurance types, coverage minimums, additional insured requirements, and waiver of subrogation language—and mapping them into a predictable, machine-readable schema. The ideal user is building or maintaining a contract review system where downstream processes, such as a vendor risk management platform or an underwriting checklist, consume these extracted fields automatically. The prompt assumes the input is a clean, machine-readable text block from a commercial agreement, such as an MSA, SOW, or vendor services contract.

Do not use this prompt when you need a full-contract risk summary or a legal opinion on coverage adequacy. It is not designed for interpreting umbrella policies, reconciling conflicting clauses across multiple documents, or providing advice on whether a coverage limit is 'market standard.' The prompt is a surgical extraction tool, not a negotiation advisor. It also should not be used on scanned documents without prior OCR processing, as layout artifacts and recognition errors will degrade the accuracy of numeric coverage amount extraction and the detection of specific legal phrases like 'primary and non-contributory.'

Before deploying this prompt, ensure your pipeline can validate the output against a strict schema. Coverage amounts must be normalized to a single currency and numeric format. Boolean fields for 'additional insured' and 'waiver of subrogation' must be explicitly true, false, or null, with null indicating the provision is absent from the text. If the prompt is used in a regulated or high-risk procurement workflow, route all extractions with a confidence score below a defined threshold for human review. The next step is to copy the prompt template, adapt the [OUTPUT_SCHEMA] to your system's contract, and run it against a golden dataset of 20-30 known clauses to establish baseline accuracy before production use.

This prompt template is designed to extract structured insurance and risk allocation data from contract text. It uses square-bracket placeholders that you replace with your actual contract text, output schema, and operational constraints before sending the prompt to a model. The template forces the model to return valid JSON with explicit null handling for missing fields, making it safe to wire directly into a contract review pipeline.

textCopy
You are a contract analysis assistant specialized in insurance and risk allocation clauses. Your task is to extract structured information from the provided contract text. Return ONLY valid JSON matching the output schema. If a field is not present or cannot be determined, use null. Do not invent or infer values.

## INPUT
Contract Text:
[CONTRACT_TEXT]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "insurance_requirements": [
    {
      "insurance_type": "string | null",
      "minimum_coverage_amount": {
        "value": "number | null",
        "currency": "string | null",
        "per_occurrence_or_aggregate": "string | null"
      },
      "additional_insured_required": "boolean | null",
      "additional_insured_entity": "string | null",
      "waiver_of_subrogation": "boolean | null",
      "primary_non_contributory": "boolean | null",
      "evidence_required": "string | null",
      "carrier_rating_requirement": "string | null",
      "source_citation": "string | null"
    }
  ],
  "indemnification_provisions": [
    {
      "indemnifying_party": "string | null",
      "indemnified_party": "string | null",
      "scope": "string | null",
      "carve_outs": ["string"],
      "survival_period": "string | null",
      "source_citation": "string | null"
    }
  ],
  "risk_allocation_notes": {
    "limitation_of_liability_cap": "string | null",
    "consequential_damages_exclusion": "boolean | null",
    "liquidated_damages": "string | null",
    "source_citation": "string | null"
  },
  "extraction_metadata": {
    "clauses_found": ["string"],
    "missing_expected_clauses": ["string"],
    "confidence_notes": "string | null"
  }
}

## CONSTRAINTS
- Return ONLY the JSON object. No markdown fences, no explanatory text.
- Use null for any field where the information is absent or ambiguous.
- For source_citation fields, quote the exact sentence or clause text that supports the extraction.
- If the contract contains no insurance or risk allocation clauses, return empty arrays and null values with a confidence note explaining the absence.
- Do not interpret silence as coverage. If a waiver of subrogation is not explicitly stated, set it to null.
- For coverage amounts, extract the numeric value and currency. Normalize "$2 million" to {"value": 2000000, "currency": "USD"}.
- Flag any contradictory or ambiguous language in confidence_notes.

## EXAMPLES
Input: "Contractor shall maintain Commercial General Liability insurance with limits of not less than $1,000,000 per occurrence and $2,000,000 aggregate. Owner shall be named as additional insured. Contractor waives all rights of subrogation against Owner."
Output:
{
  "insurance_requirements": [
    {
      "insurance_type": "Commercial General Liability",
      "minimum_coverage_amount": {
        "value": 1000000,
        "currency": "USD",
        "per_occurrence_or_aggregate": "per occurrence"
      },
      "additional_insured_required": true,
      "additional_insured_entity": "Owner",
      "waiver_of_subrogation": true,
      "primary_non_contributory": null,
      "evidence_required": null,
      "carrier_rating_requirement": null,
      "source_citation": "Contractor shall maintain Commercial General Liability insurance with limits of not less than $1,000,000 per occurrence and $2,000,000 aggregate."
    }
  ],
  "indemnification_provisions": [],
  "risk_allocation_notes": {
    "limitation_of_liability_cap": null,
    "consequential_damages_exclusion": null,
    "liquidated_damages": null,
    "source_citation": null
  },
  "extraction_metadata": {
    "clauses_found": ["insurance_requirements"],
    "missing_expected_clauses": ["indemnification_provisions", "risk_allocation_notes"],
    "confidence_notes": "Only insurance requirements found. No indemnification or liability cap language present in provided text."
  }
}

## RISK LEVEL
[HIGH_RISK: true]

To adapt this template, replace [CONTRACT_TEXT] with the full text of the contract section or clause you are analyzing. If your use case requires different insurance types or additional fields such as professional liability or cyber insurance, extend the insurance_requirements array schema. The extraction_metadata block is critical for production pipelines because it tells downstream systems which clauses were found and which were expected but absent, preventing silent failures when a contract lacks standard provisions.

Before deploying this prompt, run it against a golden dataset of at least 20 contracts with known insurance and indemnification provisions. Measure precision and recall on coverage amount extraction, additional insured detection, and waiver of subrogation identification. Pay special attention to false negatives on primary/non-contributory language, which is often implied rather than explicit. If your model consistently misses this field, add a few-shot example demonstrating the language patterns that indicate primary/non-contributory status. Always require human review for contracts above a materiality threshold, and log every extraction with its confidence notes for auditability.

This prompt is designed to be called as a single-pass extraction step within a larger document processing pipeline. The typical integration pattern is: (1) ingest and segment the contract into sections, (2) route each section through a classification step to identify insurance-related clauses, (3) pass only those candidate sections to this extraction prompt, and (4) validate the structured output before writing to your contract database. Avoid sending an entire 80-page contract to this prompt in one call—insurance provisions are usually concentrated in a few sections, and sending irrelevant text increases cost, latency, and hallucination risk. If your pipeline lacks a pre-classification step, add a lightweight insurance-section classifier prompt before invoking extraction.

Validation and retry logic is critical because coverage amounts and policy types are high-stakes fields. Implement a post-extraction validator that checks: (a) all required fields are present and non-null unless explicitly flagged as absent, (b) coverage amounts parse to numeric values with correct currency units, (c) enumerated fields like coverage_type match your internal taxonomy (e.g., commercial_general_liability, workers_compensation, professional_liability), and (d) boolean fields like waiver_of_subrogation and primary_non_contributory are actual booleans, not strings. If validation fails, retry once with the same prompt plus the validation error message appended as a [CORRECTION_HINT]. If the second attempt also fails, route the clause to a human review queue with the raw text, the failed extraction, and the specific validation errors highlighted. Never silently accept a partial extraction for insurance coverage fields.

Model choice and tool use depend on your accuracy requirements. For production contract review systems, use a model with strong structured output capabilities and low hallucination rates on legal text. Enable structured output mode (JSON mode or function calling with a strict schema) rather than relying on free-text parsing. If your platform supports it, provide the output schema as a tool definition and require the model to call the tool with the extracted fields. This gives you schema enforcement at the API level before your application code sees the response. For high-volume pipelines, consider batching multiple candidate sections into a single call with an array output schema, but keep each section's extraction independent to prevent cross-contamination.

Logging and observability should capture: the input section text, the raw model output, the validated extraction, any validation failures, retry attempts, and the final disposition (accepted, repaired, or escalated). Include a confidence field in your extraction schema and log it alongside each field. If the model reports low confidence on coverage amounts or policy types, flag those extractions for human sampling even if they pass structural validation. Over time, these logs become your evaluation dataset for measuring extraction accuracy and identifying patterns in failure modes—such as which carriers or policy structures the model consistently misreads.

Human review integration should be designed as a first-class path, not an afterthought. When an extraction is escalated, present the reviewer with: the original clause text, the model's best-effort extraction, the specific validation failures, and a structured form pre-populated with the model's output for correction. Track reviewer corrections as labeled data for future fine-tuning or prompt improvement. Set a service-level objective for extraction accuracy on coverage amounts (e.g., 99.5% numeric accuracy on audited samples) and use the human review queue volume as a leading indicator of prompt drift or model regression. If escalation rates rise above your threshold, investigate whether contract formats, carrier language, or model behavior has changed before the error reaches downstream systems.