Clause Extraction for Obligation Tracking Prompt

This prompt is designed for contract lifecycle management (CLM) engineers who need to extract ongoing obligations from legal documents and feed them into obligation tracking systems. It goes beyond simple deadline extraction by capturing trigger events, recurrence patterns, responsible parties, and deliverable descriptions in a structured schema. Use this prompt when you need to populate a compliance calendar, an obligation register, or a contract management dashboard with machine-readable obligation records.

The prompt assumes you have already isolated the relevant clauses from the full contract text. It does not perform clause isolation itself; pair it with a clause extraction prompt if you are starting from raw documents. The ideal input is a single clause or a small set of related clauses that contain obligation language—such as reporting requirements, payment schedules, delivery milestones, or audit rights. Do not use this prompt for one-time events like a closing date or a single execution action; it is optimized for recurring, conditional, and ongoing duties that span the contract lifecycle.

Before deploying, validate that your upstream clause isolation step preserves enough context for the model to identify responsible parties and trigger conditions. A common failure mode occurs when a clause references a party defined elsewhere in the contract (e.g., 'the Service Provider shall...') but the isolated text omits the definition section. In these cases, the prompt may hallucinate a party name or return a null value. Mitigate this by including a [PARTY_MAP] placeholder that provides resolved entity names from the full contract. For high-risk obligations such as regulatory filings or payment deadlines, always route outputs through human review before they enter a system of record.

This template is designed to extract ongoing obligations from contract clauses, producing structured output suitable for ingestion into an obligation management system. It expects a contract clause or full document text as input and returns a list of obligations with trigger events, deadlines, deliverables, and responsible parties. The prompt uses square-bracket placeholders that you replace with your specific contract text, output schema, and operational constraints before running it in your application.

textCopy
You are an obligation extraction engine for contract lifecycle management. Your task is to read the provided contract text and extract all ongoing obligations that require tracking after contract execution.

## INPUT
[CONTRACT_TEXT]

## OUTPUT SCHEMA
Return a JSON object with an "obligations" array. Each obligation object must follow this schema:
{
  "obligation_id": "string, unique identifier for this obligation",
  "obligation_type": "string, one of: [OBLIGATION_TYPE_TAXONOMY]",
  "description": "string, the obligation in plain language",
  "responsible_party": "string, entity responsible for performing the obligation",
  "trigger_event": "string or null, event that initiates the obligation",
  "deadline": "string or null, deadline in ISO 8601 format or relative expression",
  "recurrence_pattern": "string or null, e.g., 'monthly', 'quarterly', 'annually', 'on each anniversary'",
  "deliverable": "string or null, what must be produced or delivered",
  "condition_precedent": "string or null, condition that must be met before obligation activates",
  "source_citation": "string, section, paragraph, or clause reference from the source text",
  "confidence": "number, 0.0 to 1.0 indicating extraction confidence"
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Extract only obligations that create ongoing duties after contract signing. Exclude one-time execution requirements already satisfied at signing.
2. Normalize all temporal expressions to ISO 8601 where possible. For relative deadlines (e.g., "within 30 days of receipt"), preserve the relative expression and note the trigger.
3. If a field cannot be determined from the text, use null. Do not invent values.
4. For recurrence patterns, use standard terms: "daily", "weekly", "monthly", "quarterly", "annually", "semi-annually", or describe custom patterns explicitly.
5. Cite the exact section, clause, or paragraph where each obligation is found.
6. Set confidence below 0.7 if the obligation language is ambiguous, conditional, or spread across multiple sections.
7. If [RISK_LEVEL] is "high", flag any obligation with confidence below 0.8 for human review by setting a "requires_review" boolean field to true.

Before deploying this prompt, replace the bracketed placeholders with your specific inputs. [CONTRACT_TEXT] should contain the full clause or document text. [OBLIGATION_TYPE_TAXONOMY] should list your organization's obligation categories (e.g., "payment", "reporting", "insurance", "audit_rights"). [CONSTRAINTS] can include domain-specific rules like jurisdictional requirements or maximum dollar thresholds. [EXAMPLES] should provide at least two few-shot examples showing correct extraction from similar contracts. [RISK_LEVEL] controls whether low-confidence extractions are flagged for human review. After adapting the template, run it through your evaluation suite to verify that temporal expression normalization and recurrence pattern extraction meet your accuracy thresholds before production use.

This prompt is designed to be a single step inside a larger contract ingestion pipeline. The typical harness receives a raw clause text segment from an upstream document parser or clause splitter, enriches it with document metadata (contract ID, party names, effective date), and passes the combined context to the model. The model's structured output is then validated against the obligation schema before being written to an obligation tracking system. Do not send an entire contract to this prompt; it expects pre-isolated clause text. The upstream clause splitter should handle section boundary detection, and this prompt should receive one clause at a time to keep the extraction focused and the output schema manageable.

Validation is the critical post-processing step. After the model returns JSON, run a schema validator that checks: (1) all required fields are present and non-null unless the model explicitly set null with a null_reason, (2) obligation_type matches your internal taxonomy enum, (3) effective_date and deadline parse as valid dates or null, (4) recurrence_pattern conforms to your recurrence schema (e.g., RRULE or a simplified struct), and (5) responsible_party maps to a known entity in the contract's party list. If validation fails, retry once with the validation error message appended to the prompt as feedback. If the retry also fails, route the clause to a human review queue with the raw clause text, the failed output, and the validation errors. For high-volume pipelines, log every extraction attempt with the contract ID, clause ID, model version, prompt version, raw output, validation result, and final disposition. This audit trail is essential for debugging extraction drift and for compliance reviews.

Model choice matters for this workflow. Use a model with strong structured output support and a large context window if clauses are long. Enable structured output mode (JSON mode or function calling with a strict schema) rather than relying on free-text parsing. If your obligation tracking system requires high recall (catching every obligation), set a lower confidence threshold and route low-confidence extractions for human review rather than discarding them. If precision is more important (avoiding false positives in an automated alerting system), set a higher threshold and discard or queue uncertain results. For recurrence pattern extraction, test the model's ability to normalize temporal expressions like 'quarterly,' 'within 30 days of each anniversary,' and 'on the first business day of each month' into your canonical recurrence format. This is a common failure point that benefits from a dedicated eval set of temporal expressions with expected normalized outputs. Wire the final validated output into your obligation management system with the source clause citation preserved so downstream users can always trace an obligation back to the original contract language.