Contract Clause Fact vs Obligation Interpretation Prompt

This prompt is designed for contract review teams and legal operations engineers who need to systematically separate verifiable factual statements and defined terms from interpretive obligations, contingent clauses, and legal characterizations within contract text. Use it when you need to produce a structured decomposition of a contract clause into its factual elements (with precise clause references) and its obligation interpretations (which require legal judgment). This is not a replacement for legal counsel; it is a pre-processing step for downstream review, obligation tracking, or contract analysis pipelines where mixing facts with interpretation leads to misclassification and over-confident automation outputs.

The ideal user is an engineer or legal operations professional building a contract analysis pipeline. You have already extracted or isolated a specific clause and now need to separate its atomic, verifiable components from the conditional and judgment-laden language that surrounds them. The prompt requires a single, well-scoped clause as input—not an entire contract. It works best when you provide explicit output schemas for both the facts and obligations arrays, including field-level constraints like clause_reference (e.g., 'Section 2.1(a)') and requires_legal_review flags. If your input is a full contract, you must first use a clause-extraction or document-intelligence prompt to isolate the target text.

Do not use this prompt when you need a definitive legal opinion on a clause's meaning, when you are assessing overall contract risk, or when the input is a negotiation transcript or email thread rather than formal contract language. It is also inappropriate for clauses that are purely definitional or boilerplate without any operative language, as the obligation extraction step will produce low-value or misleading output. For high-risk contracts, always route the output to a human reviewer and log the model's confidence scores alongside the structured decomposition. The next step after reading this section is to review the prompt template and adapt the [OUTPUT_SCHEMA] to match your downstream system's contract model.

This prompt template is designed for contract review teams who need to systematically separate verifiable factual elements and defined terms from interpretive obligations, contingent clauses, and legal characterizations within contract language. The template forces the model to produce structured output with clause references, making it suitable for integration into legal review pipelines where traceability and audit readiness are required. Replace the square-bracket placeholders with your specific contract text, jurisdiction context, and output requirements before use.

textCopy
You are a contract analysis assistant. Your task is to separate stated facts and defined terms from interpretive obligations, contingent clauses, and legal characterizations in the provided contract clause.

## INPUT
[CONTRACT_CLAUSE_TEXT]

## CONTEXT
- Jurisdiction: [JURISDICTION]
- Contract Type: [CONTRACT_TYPE]
- Governing Law: [GOVERNING_LAW]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "clause_reference": "string (section or clause identifier)",
  "factual_elements": [
    {
      "element_id": "string",
      "statement": "string (exact factual assertion or defined term)",
      "source_span": "string (exact text from clause)",
      "element_type": "stated_fact | defined_term | recital | representation",
      "verifiability": "directly_verifiable | requires_document_reference | not_independently_verifiable"
    }
  ],
  "obligation_interpretations": [
    {
      "interpretation_id": "string",
      "statement": "string (the interpreted obligation)",
      "source_span": "string (exact text from clause)",
      "interpretation_type": "covenant | condition_precedent | condition_subsequent | contingent_obligation | discretionary_right | legal_characterization | risk_allocation",
      "triggering_condition": "string or null (what must occur for obligation to activate)",
      "requires_legal_judgment": true,
      "alternative_interpretations": ["string (other reasonable readings)"]
    }
  ],
  "embedded_factual_assertions_in_obligations": [
    {
      "assertion_id": "string",
      "statement": "string (factual claim embedded within conditional or obligational language)",
      "source_span": "string",
      "parent_interpretation_id": "string (links to obligation_interpretations)",
      "verifiability": "string"
    }
  ],
  "boundary_notes": "string (explain any passages where fact-interpretation separation was ambiguous)"
}

## CONSTRAINTS
- Do not classify a statement as factual if it requires legal interpretation to determine its meaning or scope.
- Flag any factual assertions that appear inside conditional or obligational language as embedded_factual_assertions_in_obligations.
- For each obligation interpretation, provide at least one alternative reasonable reading if one exists.
- Mark all obligation interpretations with requires_legal_judgment: true.
- If the clause contains no factual elements, return an empty factual_elements array with a boundary_note explaining why.
- Preserve exact source text in source_span fields without paraphrasing.

## RISK LEVEL
[RISK_LEVEL: high | medium | low]
- If RISK_LEVEL is high: Flag all interpretations for human review and do not assert a single definitive reading.
- If RISK_LEVEL is medium: Provide confidence indicators for each interpretation.
- If RISK_LEVEL is low: Proceed with standard separation but note any residual ambiguity.

To adapt this template, start by replacing [CONTRACT_CLAUSE_TEXT] with the specific clause you are reviewing. Set [JURISDICTION] and [GOVERNING_LAW] to the relevant legal context, as these influence how obligations are characterized. The [RISK_LEVEL] parameter controls the model's caution: use high for material clauses, termination rights, or indemnification provisions where misinterpretation carries significant consequences. For high-risk clauses, always route the obligation_interpretations output to a qualified legal reviewer before any downstream system acts on the extracted structure. The embedded_factual_assertions_in_obligations array is critical for catching factual claims that might otherwise be treated as interpretive, such as a representation about a party's status buried inside a condition precedent.

This prompt is designed as a pre-processing step before downstream contract review, obligation tracking, or risk analysis. It should be integrated into a pipeline that ingests contract text, runs this separation prompt, and routes the two output streams—factual elements and interpretive obligations—to different handlers. The factual stream (defined terms, dates, parties, stated values) can feed directly into structured extraction and database ingestion. The obligation stream (conditional duties, legal characterizations, contingent clauses) must be routed to a human review queue or a secondary legal reasoning model, never treated as ground truth. The prompt itself does not make legal judgments; it classifies content by type and flags where interpretation begins.

Wire the prompt into your application with a pre-validation step that checks for minimum contract length (at least 200 words to avoid trivial inputs) and maximum length (split documents exceeding ~8,000 tokens into sections with overlap). Use a structured output schema requiring the model to return JSON with two arrays: factual_elements (objects with clause_reference, statement, certainty) and obligation_interpretations (objects with clause_reference, interpretation, contingency_flag, requires_legal_review). Implement a post-processing validator that rejects any output where requires_legal_review is false for conditional language containing terms like 'subject to', 'provided that', 'notwithstanding', or 'unless'. Add a retry loop with a maximum of two attempts if the JSON schema is malformed or if factual elements lack clause references. Log every output with a trace ID, the model version, and the confidence scores for auditability. For high-stakes contracts, route all obligation interpretations to a human-in-the-loop review interface that displays the original clause text alongside the model's classification, allowing the reviewer to confirm, reclassify, or add notes before the data enters any downstream system.

Choose a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate starting points. Avoid smaller or older models that may conflate factual statements with interpretive language under conditional phrasing. Set temperature to 0 or near-zero to maximize consistency across repeated runs on the same contract. If using the prompt inside a RAG or retrieval system, ensure the contract text is passed in full as [INPUT] rather than chunked, because clause references and cross-references require whole-document context. For batch processing of contract repositories, implement rate limiting, cost tracking per document, and a dead-letter queue for outputs that fail validation after retries. The next step after successful separation is to feed factual elements into a structured contract database and route obligation interpretations to a legal review workflow with the original clause text attached.