Missing Liability Cap Detection Prompt

Risk review teams and legal engineers use this prompt to systematically analyze contracts for limitation of liability clauses. The prompt extracts cap amounts, identifies cap types (e.g., hard cap, fee-based cap, supercap for specific breaches), and explicitly flags contracts where liability caps are missing, uncapped, or have unclear carve-outs. This is not a general contract summary prompt. Use it when you need structured, auditable output about liability exposure that can feed into a risk scoring system, a compliance checklist, or a human review queue.

The prompt is designed for production pipelines where silent failures from missing data cause downstream errors that are harder to detect than explicit uncertainty flags. It requires the full contract text as input and expects a defined output schema with fields for cap presence, cap amount, cap type, carve-outs, and confidence scores. The prompt works best when paired with a clause isolation step that extracts the limitation of liability section before analysis, reducing noise from unrelated contract language. For multi-tier cap structures—where different caps apply to different breach types—the prompt returns an array of cap entries rather than a single value.

Do not use this prompt for general contract summarization, obligation extraction, or clause review outside liability caps. It is not designed for contracts governed by jurisdictions where liability limitation language follows non-standard patterns without adaptation. For high-risk contracts, always route outputs with missing-cap flags or low confidence scores to human review before the data enters a risk scoring system. Pair this prompt with the Null Handling Prompt for JSON Extraction to ensure downstream systems can distinguish between 'cap not found,' 'cap explicitly waived,' and 'analysis failed.'

This prompt template is designed to be dropped into a document review pipeline where the input is a full contract or a pre-isolated limitation of liability clause. It instructs the model to extract structured information about liability caps—including cap amounts, types, and applicable carve-outs—and to explicitly flag when a cap is missing, uncapped, or has unclear boundaries. The template uses square-bracket placeholders so you can adapt it to your specific risk policy, output schema, and contract domain without rewriting the core logic.

textCopy
You are a contract risk analyst assistant. Your task is to examine the provided contract text and determine whether a limitation of liability clause exists, and if so, extract the liability cap details. If no such clause is found, or if the cap is missing, uncapped, or ambiguous, you must flag it explicitly.

## INPUT
[CONTRACT_TEXT]

## RISK POLICY
[RISK_POLICY]

## OUTPUT SCHEMA
You must return a single JSON object conforming to this structure:
{
  "liability_cap_present": boolean,
  "cap_details": [
    {
      "cap_type": "general" | "per_claim" | "aggregate" | "per_incident" | "other",
      "cap_amount": number | null,
      "currency": string | null,
      "cap_description": string,
      "source_section": string,
      "confidence": "high" | "medium" | "low"
    }
  ],
  "uncapped_liabilities": [
    {
      "liability_type": string,
      "source_section": string
    }
  ],
  "carve_outs": [
    {
      "carve_out_type": string,
      "description": string,
      "source_section": string
    }
  ],
  "flags": {
    "missing_clause": boolean,
    "uncapped": boolean,
    "ambiguous_cap": boolean,
    "multi_tier_structure": boolean,
    "requires_human_review": boolean
  },
  "summary": string
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. First, scan the entire [CONTRACT_TEXT] for any limitation of liability clause. If none is found, set `flags.missing_clause` to true, `liability_cap_present` to false, and `flags.requires_human_review` to true. Provide a brief summary explaining the absence.
2. If a clause is found, extract every cap mentioned. A contract may have multiple caps (e.g., a general cap and a separate cap for IP infringement). Capture each in the `cap_details` array.
3. For each cap, determine the `cap_type`. If the type is unclear, use "other" and explain in `cap_description`.
4. If a cap amount is stated as a formula, a reference to another document, or an insurance policy limit, set `cap_amount` to null and note the dependency in `cap_description`. Set `confidence` to "low".
5. If the clause explicitly states there is no cap on certain liabilities (e.g., fraud, death, gross negligence), list each in `uncapped_liabilities`.
6. Identify any carve-outs that reduce or exclude certain damages from the cap (e.g., indemnification obligations, data breach costs). List each in `carve_outs`.
7. Set `flags.uncapped` to true if the contract has no cap at all or if the cap is stated as unlimited.
8. Set `flags.ambiguous_cap` to true if the cap language is contradictory, references missing schedules, or uses vague terms like "to the extent permitted by law" without a stated amount.
9. Set `flags.multi_tier_structure` to true if the contract has different caps for different liability types.
10. Set `flags.requires_human_review` to true if any confidence is "low", if the cap is missing, or if the cap structure is complex enough that automated extraction could be unreliable.
11. For every extracted field, include a `source_section` reference (e.g., "Section 8.2(a)") so a human reviewer can verify the finding.
12. If [RISK_POLICY] specifies a required minimum cap or prohibited uncapped liabilities, compare the extracted details against the policy and note any violations in the `summary`.

To adapt this template, replace the placeholders with your specific context. [CONTRACT_TEXT] should be the full contract body or the pre-extracted clause. [RISK_POLICY] can be a short natural-language statement of your organization's risk tolerance (e.g., "Liability caps below 2x contract value require escalation. Uncapped liability for data breaches is prohibited."). [CONSTRAINTS] can include domain-specific rules like "Ignore liability caps in the 'Insurance' section unless cross-referenced by the limitation of liability clause." [EXAMPLES] should contain one or two few-shot demonstrations of correctly parsed outputs, including an example of a missing cap and an example of a multi-tier structure. After adapting, run the prompt against a golden dataset of contracts with known cap structures and compare the flags.requires_human_review field against your risk team's actual review decisions to calibrate the threshold.

This prompt is designed to be called as part of a document processing pipeline, not as a standalone chat interaction. The typical integration pattern involves: (1) chunking the contract into sections with preserved heading hierarchy, (2) routing only the limitation-of-liability-relevant sections to this prompt to control context cost, (3) parsing the structured JSON output, and (4) applying post-processing validation before the result reaches a reviewer or downstream system. Because missing liability caps represent a material contract risk, the implementation must treat both 'cap found' and 'cap absent' results as equally important signals—a silent failure where the model misses a cap is more dangerous than a false positive that triggers human review.

Validation layer. Before the output is trusted, apply a schema validator that checks: the liability_cap_detected boolean is present; if true, cap_amount, cap_type, and currency fields are non-null; source_citation includes at least a section reference; and carve_outs is an array even if empty. Add a business-rule validator that flags: caps expressed as a formula rather than a fixed amount (e.g., 'fees paid in the prior 12 months'), multi-tier caps where only one tier was extracted, and caps that reference schedules or exhibits not yet processed. Reject outputs that fail schema validation and retry with the same prompt plus the validation error message appended as a [VALIDATION_ERROR] context block. After two retries, escalate to a human review queue with the raw model output and validation trace attached.

Model choice and configuration. Use a model with strong legal text reasoning and structured output support, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Set temperature to 0 or near-zero to minimize variance in extraction. If the model supports structured output mode (e.g., OpenAI's response_format with a JSON schema or Claude's tool-use with a defined schema), use it rather than relying solely on prompt instructions—this reduces parsing failures. For high-throughput pipelines processing hundreds of contracts, consider a two-stage architecture: a cheaper classifier model first determines whether a limitation-of-liability clause exists anywhere in the document, and only routes positive or uncertain cases to this detailed extraction prompt.

Logging and audit trail. Log every invocation with: the prompt version hash, the model ID, the input section text, the raw output, the parsed output, validation results, retry count, and the final disposition (passed, flagged for review, escalated). This audit trail is critical for contract review workflows because downstream decisions—such as whether to sign an agreement—may depend on the cap detection result. Store the source_citation field alongside the extracted cap so reviewers can click directly to the relevant contract section. For regulated industries, ensure logs are immutable and retained according to your document retention policy.

Human review integration. When the prompt returns liability_cap_detected: false or confidence: low, route the contract to a review queue with a pre-filled summary: 'No liability cap detected in sections [X, Y, Z]. Model confidence: [value]. Recommended action: Manual review of limitation of liability.' When a cap is detected but carve-outs are flagged as 'unclear' or 'broad,' surface those carve-outs prominently in the review UI so the reviewer can assess whether the cap is effectively unlimited. Never allow an automated 'no cap found' result to close a risk review task without human confirmation unless you have measured and accepted the false-negative rate against your risk tolerance.

What to avoid. Do not use this prompt on a full contract document without first extracting the relevant sections—context-window limits and attention dilution will degrade extraction quality on long documents. Do not treat the model's output as a legal determination; the prompt is a detection and extraction tool, not a replacement for legal judgment. Do not skip the validation layer; raw model outputs will occasionally produce malformed JSON, missing fields, or hallucinated section references that must be caught before the result enters a system of record.