Multi-Version Definition Drift Prompt

Legal knowledge teams and contract operations engineers need to track how defined terms evolve across contract versions. A term like 'Confidential Information' or 'Material Adverse Effect' can shift in scope, exclusions, or cross-references between amendments, restatements, and related agreements. Manual tracking is slow, error-prone, and misses downstream impacts on dependent clauses. This prompt produces a structured definition change log with before/after text, version context, and impact assessment on clauses that rely on the changed definition. Use it when you have multiple versions of the same contract or a portfolio of related agreements and need to identify where definitions drifted, when they changed, and which obligations, representations, or conditions are affected.

This prompt belongs in contract review pipelines, due diligence workflows, and legal knowledge management systems where definitional consistency matters for risk assessment and compliance. It is designed for scenarios where you have at least two versions of a document with defined terms sections—typically Article 1 or a Definitions schedule—and need to produce a machine-readable change log. The ideal input includes the full text of each version, version metadata (effective date, amendment number, governing document), and a list of defined terms to track. If you don't provide a term list, the prompt will extract all defined terms from each version, but this increases token usage and may surface formatting-only changes that aren't material.

Do not use this prompt for single-document definition extraction without version comparison—use a dedicated clause extraction prompt instead. Avoid it when you need real-time legal advice or when the documents are heavily redacted, as missing text will produce false negatives. This prompt also isn't suitable for comparing definitions across unrelated contracts from different counterparties unless you explicitly provide precedence rules. For high-stakes transactions, always pair the output with human review, especially when the impact assessment flags obligations or liability provisions that depend on a changed definition. The prompt is a detection and structuring tool, not a replacement for legal judgment.

This prompt template is designed for legal knowledge teams who need to systematically track how defined terms evolve across multiple contract versions. Instead of manually comparing definitions line by line, the prompt instructs the model to produce a structured change log that captures the exact before-and-after text for each altered definition, identifies the version where the change occurred, and assesses how the change affects dependent clauses throughout the document. The output is intended to be machine-readable for downstream ingestion into contract management systems, but it also includes human-readable impact notes for legal reviewers.

textCopy
You are a legal definition analyst tracking how defined terms change across contract versions.

You will receive multiple versions of a contract in chronological order. Each version is labeled with a version identifier and effective date.

Your task is to produce a structured definition change log that identifies every defined term that changed between versions, captures the exact before-and-after text, and assesses the impact on dependent clauses.

## INPUT

[VERSIONS]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "document_set": string,
  "analysis_date": string,
  "version_count": number,
  "definition_changes": [
    {
      "term": string,
      "change_id": string,
      "change_type": "added" | "modified" | "removed" | "scope_changed",
      "version_context": {
        "introduced_in_version": string,
        "effective_date": string,
        "previous_version": string | null
      },
      "before": {
        "definition_text": string | null,
        "section_citation": string | null,
        "scope_notes": string | null
      },
      "after": {
        "definition_text": string | null,
        "section_citation": string | null,
        "scope_notes": string | null
      },
      "change_summary": string,
      "impact_assessment": {
        "affected_clauses": [
          {
            "clause_reference": string,
            "clause_text_excerpt": string,
            "impact_description": string,
            "severity": "high" | "medium" | "low"
          }
        ],
        "cross_references_affected": [string],
        "overall_risk_shift": string
      },
      "confidence": "high" | "medium" | "low",
      "reviewer_notes": string
    }
  ],
  "unchanged_definitions": [
    {
      "term": string,
      "last_modified_version": string,
      "current_definition_summary": string
    }
  ],
  "analysis_notes": string
}

## CONSTRAINTS

- Only report changes to defined terms. Do not report changes to ordinary language or non-definitional clauses unless they directly alter a defined term's meaning.
- For each change, cite the exact section, paragraph, or page where the definition appears in both the before and after versions.
- If a definition is removed entirely, set after.definition_text to null and explain what replaced it or why it was removed.
- If a definition is newly added, set before.definition_text to null.
- For scope_changed changes, explain how the term's applicability expanded or contracted even if the definition text itself remained similar.
- Flag any dependent clauses that use the defined term and would be materially affected by the change. Include the clause text excerpt so reviewers can verify without opening the source document.
- Set confidence to "low" if the definition text is ambiguous, partially redacted, or spans multiple sections that may be incomplete.
- Include reviewer_notes for any change that requires human legal judgment before the change log is considered final.
- Do not invent definitions, clauses, or version identifiers. Only use text present in the provided [VERSIONS].

## EXAMPLES

[EXAMPLES]

## RISK LEVEL

[RISK_LEVEL]

To adapt this template, replace [VERSIONS] with the full text of each contract version, clearly labeled with version identifiers and effective dates. The [EXAMPLES] placeholder should contain one or two representative before-and-after definition pairs with correct impact assessments to calibrate the model's output quality. Set [RISK_LEVEL] to "high" if the contracts involve material financial obligations, regulatory compliance, or litigation exposure, which should trigger mandatory human review of every change flagged with medium or low confidence. For lower-risk document sets, you may adjust the review threshold accordingly. After receiving the model output, validate that every cited section reference exists in the source documents and that no definitions were missed by comparing the total count of defined terms across versions against the change log.

The Multi-Version Definition Drift Prompt is designed to operate as a single step within a larger document processing pipeline, not as a standalone chat interaction. The application layer is responsible for version pairing, context assembly, output validation, and escalation. Before invoking the model, the harness must extract the full text of each contract version, identify the version sequence (v1, v2, v3, etc.), and pass only the relevant version pair plus the defined term of interest. Attempting to pass all versions simultaneously for a single term degrades accuracy; instead, iterate pairwise through the version history for each term and merge the results into a consolidated change log.

Input assembly: For each defined term, construct the prompt with the term name, the full text of the earlier version, the full text of the later version, and any known definition sections to constrain the search space. If the document has a dedicated 'Definitions' or 'Article 1' section, pass that as [CONTEXT] to reduce hallucinated matches from usage instances rather than formal definitions. Model choice: Use a model with strong instruction-following and long-context handling (e.g., GPT-4o, Claude 3.5 Sonnet) because definition clauses can be separated from their dependent clauses by many pages. Output validation: Parse the JSON output and validate that every before_text and after_text field contains a verbatim substring match in the corresponding source document. If the extracted text does not appear in the source, flag the change for human review and do not auto-apply it to the change log. This substring-match check catches hallucinated definition text, which is the most common failure mode.

Retry logic: If validation fails, retry once with the same prompt plus the validation error message appended as a [CONSTRAINTS] update, instructing the model to only quote text that appears verbatim in the provided source. If the retry also fails, escalate the term-version pair to a human review queue with the source documents, the failed output, and the specific validation errors. Logging and audit: Log every invocation with the term name, version pair, raw model output, validation result, and reviewer decision. This audit trail is essential for legal workflows where definition drift claims must be defensible. Human review gate: For high-risk terms (e.g., 'Indebtedness,' 'Material Adverse Effect,' 'Confidential Information'), always route the output to a legal reviewer regardless of validation pass/fail. The prompt's impact_assessment field is a useful triage signal—changes rated 'High' impact should never auto-commit to a system of record without human approval.

Integration pattern: Wire this prompt as a function call within a document processing service. The service should: (1) accept a document version set and a list of tracked terms, (2) for each term, iterate through consecutive version pairs, (3) call the LLM with the prompt template, (4) validate substring matches, (5) merge pairwise results into a chronological change log, and (6) publish validated changes to the contract management system with audit metadata. Avoid the temptation to batch multiple terms into a single prompt call—definition drift analysis requires focused attention per term, and batching increases the risk of missed changes and cross-term confusion.