Legal Obligation Extraction Prompt for Vendor Contracts

This prompt is built for procurement operations, legal operations, and contract compliance teams who need to convert dense vendor agreements into a machine-readable inventory of actionable obligations. The core job-to-be-done is answering: who must do what by when, what happens if they don't, and which obligations are conditional or triggered by renewal. The ideal user is a contract analyst or operations specialist who has access to clean, extracted text from a single vendor agreement and needs structured records that can be ingested directly into a contract lifecycle management (CLM) system, obligation tracker, or compliance database.

Use this prompt when you have a single vendor agreement as input and the text has already been extracted from PDF or scanned documents. The prompt assumes the input is clean plain text, not an image or a multi-document portfolio. It is designed for commercial vendor contracts—master service agreements, SaaS subscriptions, supply agreements, and statements of work. Do not use this prompt for M&A agreements, employment contracts, litigation filings, or real estate leases. Those document types have different obligation structures, risk profiles, and legal review requirements that this prompt's schema does not address. The prompt does not provide legal advice and does not replace attorney review; every extracted obligation must be traceable to its source clause.

Before running this prompt, ensure you have a clear output schema defined for your target system. The prompt works best when you specify the exact fields your obligation tracker expects—such as obligation_id, responsible_party, deadline, deliverable, consequence, condition, and source_clause. If your contract contains exhibits, schedules, or amendments, decide whether to process them as part of the same input or as separate extraction passes. For high-risk contracts, always route the extracted obligation inventory through a human review queue before it enters a system of record. The next section provides the copy-ready prompt template you can adapt to your schema and risk level.

This prompt template is designed to be pasted directly into your system instructions for a model call. It instructs the model to act as a contract analyst, extracting actionable obligations from vendor agreements into a strict JSON schema. The template uses square-bracket placeholders for all dynamic inputs, such as the contract text, risk tolerance, and output schema. Before using it, ensure you have defined your target obligation types, responsible party taxonomy, and any jurisdiction-specific rules that should govern extraction.

textCopy
You are a contract analysis assistant. Your task is to extract all actionable legal obligations from the provided vendor contract text.

## Input
[CONTRACT_TEXT]

## Extraction Rules
1.  **Identify Obligations:** Find every clause that mandates an action, delivery, payment, notice, or forbearance by either party.
2.  **Extract Key Fields:** For each obligation, extract the following fields precisely:
    - `obligation_id`: A unique identifier for this obligation (e.g., "OB-001").
    - `description`: A concise, one-sentence summary of the required action.
    - `responsible_party`: The entity obligated to perform the action. Use values from [PARTY_TAXONOMY].
    - `deadline`: The specific date, timeframe, or triggering event. Use ISO 8601 for dates where possible. If relative, describe the trigger (e.g., "30 days after Effective Date").
    - `deliverable`: The specific item, service, or outcome to be provided. Use "N/A" if not applicable.
    - `consequence`: The penalty, remedy, or next step if the obligation is not met. Use "Not Specified" if absent.
    - `conditionality`: Describe any preconditions or dependencies. Use "Unconditional" if none exist.
    - `source_text`: The verbatim text from the contract that defines this obligation.
3.  **Handle Ambiguity:** If a field's value is ambiguous or cannot be determined, set its value to `null` and add a note to the `confidence_notes` field explaining the ambiguity.
4.  **Conditional Obligations:** Explicitly extract obligations that are triggered by a future event (e.g., renewal, hitting a spend threshold). Describe the trigger in the `conditionality` field.

## Constraints
- Do not invent obligations not present in the text.
- Do not provide legal advice or interpret the fairness of a clause.
- If no obligations are found, return an empty `obligations` array.
- Adhere strictly to the [OUTPUT_SCHEMA].

## Output Schema
You must output a single JSON object matching this structure:
{
  "obligations": [
    {
      "obligation_id": "string",
      "description": "string",
      "responsible_party": "string | null",
      "deadline": "string | null",
      "deliverable": "string | null",
      "consequence": "string | null",
      "conditionality": "string | null",
      "source_text": "string",
      "confidence_notes": "string | null"
    }
  ],
  "extraction_metadata": {
    "contract_id": "[CONTRACT_ID]",
    "parties_identified": ["string"],
    "extraction_timestamp": "string"
  }
}

To adapt this template, replace the placeholders with your specific data and configuration. [CONTRACT_TEXT] should be the full text of the vendor agreement. [PARTY_TAXONOMY] should be a list of canonical party names from your contract management system (e.g., "Acme Corp", "Our Company Inc."). [CONTRACT_ID] is your internal identifier for the document. For high-stakes contracts, always route outputs where confidence_notes is not null or consequence is "Not Specified" to a human reviewer for validation before the data is ingested into downstream obligation-tracking systems.

This prompt is designed to be called from an application layer that manages document chunking, model invocation, and output validation. The typical integration pattern involves splitting a vendor contract into sections or pages, sending each chunk through the prompt with shared [CONTRACT_METADATA] (vendor name, effective date, governing law), and then merging the resulting obligation arrays into a single structured record set. Because legal extraction is high-risk, the application must never treat the model's output as authoritative without downstream verification. The prompt's [CONFIDENCE_THRESHOLD] parameter should be wired to a configurable application setting (default 0.85) that determines whether an extracted obligation is auto-accepted or routed to a legal reviewer.

Validation and retry logic is critical. The application should validate each model response against the expected JSON schema before accepting it. If an obligation record is missing required fields (obligation_id, responsible_party, obligation_description, deadline), or if confidence_score falls below the threshold, the application should trigger a retry with the same chunk and an additional [RETRY_CONTEXT] that includes the specific validation error. Limit retries to two attempts per chunk. After two failures, flag the chunk for human review and log the raw model response, the validation errors, and the chunk text for diagnosis. Use a structured logging format that captures contract_id, chunk_index, model_id, prompt_version, latency_ms, and validation_errors for every invocation.

Model choice and tool use should favor models with strong instruction-following and structured output capabilities. For high-volume contract processing, consider using a model that supports native JSON mode or structured output constraints (such as GPT-4o with response_format or Claude with tool-use schemas) to reduce malformed JSON rates. If your contract pipeline includes a retrieval step—for example, pulling relevant clauses from a contract repository before extraction—wire the prompt's [CONTEXT] field to the RAG-retrieved passages and ensure the retriever preserves page and section metadata for citation. Do not use this prompt with models that lack reliable JSON output; the cost of malformed obligation records in a legal workflow is too high.

Human review integration is mandatory for obligations that meet any of these conditions: confidence below threshold, conditional obligations with unresolved triggers, obligations flagged with risk_level: 'high', or any obligation where consequence_clause indicates material financial or regulatory exposure. The application should push these records to a review queue with the original contract text, the extracted obligation, and a pre-filled accept/edit/reject interface. Track reviewer decisions to build a feedback dataset for future prompt improvements and fine-tuning. Never auto-ingest extracted obligations into a system of record (CLM, ERP, compliance tracker) without either passing the confidence threshold or receiving human approval. The prompt's [REVIEW_REQUIRED] output field should be mapped directly to your application's routing logic—if true, the record must not proceed automatically.