Contractual Obligation Verification Prompt Template

This prompt is designed for contract management and legal operations teams that need to systematically verify whether contractual obligations have been fulfilled. The core job-to-be-done is taking a contract document and a set of fulfillment evidence records—such as deliverables, payment receipts, and correspondence—and producing a structured compliance report. The ideal user is a contract analyst, paralegal, or legal operations professional who understands the contract's context but needs an AI harness to accelerate the tedious, error-prone work of cross-referencing obligations against evidence. The prompt extracts obligations, conditions, and deadlines, then checks each against the provided evidence to flag gaps, track dependencies, and surface breach risk before a human reviewer makes the final call.

You should use this prompt when you have a defined contract and a discrete set of evidence records to verify against it. It works best for contracts with explicit, verifiable obligations such as delivery milestones, payment schedules, reporting requirements, and regulatory commitments. The prompt requires structured inputs: the full contract text, a list of evidence items with descriptions and dates, and optionally a risk threshold that determines which gaps get flagged. It is not suitable for implied obligations, good-faith clauses, or subjective performance assessments where the contract language is intentionally vague. Do not use this prompt for contract drafting, negotiation strategy, or as a replacement for legal counsel—it is a verification harness, not a legal advisor.

Before using this prompt, ensure your evidence records are complete and accurately dated. The prompt's breach risk flags depend on deadline comparisons, so missing or incorrectly dated evidence will produce false positives. You should also define your output schema expectations upfront: whether you need a simple pass/fail per obligation, a detailed gap analysis with evidence citations, or a full compliance report with dependency chains. The prompt template includes placeholders for these constraints. After running the prompt, always route the output to a human reviewer for final sign-off, especially for high-risk obligations where breach consequences are severe. The next section provides the copy-ready prompt template you can adapt to your contract types and evidence formats.

This prompt template is designed to be pasted directly into your AI harness. It instructs the model to act as a contract analyst, extracting obligations, conditions, and deadlines from a source contract and then cross-referencing them against a set of provided evidence documents. The template uses square-bracket placeholders for all variable inputs, allowing you to swap in different contracts, evidence sets, and output schemas without rewriting the core instructions. The prompt is structured to enforce a strict verification workflow: first extract, then match to evidence, and finally flag any gaps or breach risks.

codeCopy
You are a contract obligation verification analyst. Your task is to extract all obligations, conditions, and deadlines from the provided contract and verify their fulfillment status against the provided evidence.

# CONTRACT
[CONTRACT_TEXT]

# EVIDENCE
[EVIDENCE_DOCUMENTS]

# INSTRUCTIONS
1.  **Extract Obligations:** Identify every clause that imposes a duty, condition, deadline, payment, deliverable, or restriction on any party. For each obligation, extract:
    - `obligation_id`: A unique identifier (e.g., OB-001).
    - `party`: The party responsible for fulfilling the obligation.
    - `description`: A clear, atomic description of what must be done.
    - `deadline`: The specific date or condition for fulfillment, if stated.
    - `dependencies`: List of `obligation_id`s that must be completed first.
2.  **Verify Against Evidence:** For each extracted obligation, search the provided evidence to determine its status.
    - `status`: Must be one of `FULFILLED`, `PARTIALLY_FULFILLED`, `NOT_FULFILLED`, or `INSUFFICIENT_EVIDENCE`.
    - `evidence_citation`: A verbatim quote from the evidence that supports the status determination. If `INSUFFICIENT_EVIDENCE`, state what specific evidence is missing.
    - `breach_risk`: A `HIGH`, `MEDIUM`, or `LOW` assessment of the risk that the obligation is in breach, based on the evidence and the deadline.
3.  **Output Format:** Return your findings as a single JSON object conforming to the schema below. Do not include any text outside the JSON object.

# OUTPUT_SCHEMA
{
  "contract_title": "string",
  "verification_date": "YYYY-MM-DD",
  "obligations": [
    {
      "obligation_id": "string",
      "party": "string",
      "description": "string",
      "deadline": "string | null",
      "dependencies": ["string"],
      "status": "FULFILLED | PARTIALLY_FULFILLED | NOT_FULFILLED | INSUFFICIENT_EVIDENCE",
      "evidence_citation": "string",
      "breach_risk": "HIGH | MEDIUM | LOW"
    }
  ],
  "unverifiable_obligations_count": "number",
  "high_breach_risk_count": "number"
}

# CONSTRAINTS
- Do not invent obligations not present in the contract text.
- If the evidence is a scanned document or image, state that text extraction may be unreliable.
- For any `INSUFFICIENT_EVIDENCE` status, you must not guess the fulfillment state.
- If the contract references external documents not provided in the evidence, flag this as a limitation in your analysis.

To adapt this template, replace the [CONTRACT_TEXT] and [EVIDENCE_DOCUMENTS] placeholders with your actual content. For production use, you should modify the OUTPUT_SCHEMA to match your application's data model. The constraints section is critical for high-stakes legal workflows; it prevents the model from hallucinating obligations or guessing fulfillment status when evidence is missing. Before deploying, run this prompt against a golden dataset of contracts with known obligations and evidence to measure extraction recall and verification precision. Always route outputs with a breach_risk of HIGH or a status of INSUFFICIENT_EVIDENCE for human review before taking any automated action.

This prompt is designed to sit inside a contract review pipeline, not as a standalone chat interface. The typical integration flow is: (1) ingest the contract text and any supporting evidence documents, (2) run this prompt to extract obligations and verify their fulfillment status, (3) validate the structured output against a schema, (4) route high-risk or low-confidence findings to human review, and (5) store the verified obligation records in a contract management system. The prompt expects two primary inputs: the full contract text in [CONTRACT_TEXT] and any available evidence of fulfillment in [EVIDENCE_DOCUMENTS]. If evidence is missing or incomplete, the prompt is instructed to flag obligations as UNVERIFIED rather than guessing, which is critical for audit defensibility.

Model choice and latency considerations: This prompt works best with models that have strong reasoning capabilities and large context windows, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Contracts often exceed 50 pages, so plan for context packing. If the contract plus evidence exceeds the model's context limit, implement a chunking strategy: split the contract by article or section, run the prompt per chunk, and deduplicate obligations that span section boundaries. For batch processing of multiple contracts, use asynchronous API calls with a concurrency limit appropriate for your rate tier. Expect 15-45 seconds per contract depending on length and model choice. Validation layer: The output schema includes obligation ID, description, source clause reference, party responsible, deadline, conditions precedent, fulfillment status, evidence references, and breach risk flags. Before storing results, validate that every obligation has a non-empty source_clause_reference (to prevent hallucinated obligations), that fulfillment_status is one of the enum values (FULFILLED, PARTIALLY_FULFILLED, UNFULFILLED, UNVERIFIED, NOT_YET_DUE), and that any obligation marked FULFILLED has at least one evidence_reference with a document identifier and excerpt. Reject records that fail validation and retry with a repair prompt that includes the specific validation errors.

Retry and self-correction strategy: If the model returns malformed JSON, use a repair prompt that feeds the raw output and validation errors back to the model with instructions to fix only the structural issues while preserving the obligation content. Limit repairs to two attempts before escalating to human review. For low-confidence outputs (where the model's internal confidence or the breach_risk flag is HIGH), route directly to a review queue. Human review integration: Package each flagged obligation with the source clause text, the evidence excerpts the model cited, and the model's reasoning for the risk flag. This gives reviewers enough context to make a decision without re-reading the entire contract. Store reviewer decisions (confirmed, overridden, escalated) as feedback for prompt iteration. Logging and observability: Log every prompt run with a trace ID, contract identifier, model version, prompt version, token usage, latency, validation pass/fail, and human review outcome. This audit trail is essential for legal operations teams who need to demonstrate review diligence. What to avoid: Do not use this prompt for real-time contract negotiation or as a substitute for legal advice. The prompt identifies obligations and flags risks but does not interpret legal consequences or recommend actions. Always require human review for obligations with breach_risk: HIGH or fulfillment_status: UNVERIFIED before taking any business action.