Structured Diff Output Prompt with Source Attribution

This prompt is designed for document pipeline engineers who need to compare two document versions and produce a structured, machine-readable diff. It is not a redline renderer or a human-facing summary tool. Use it when your application must ingest comparison output into a database, trigger downstream workflows, or feed a review queue. The prompt generates a JSON array of change objects, each with a change type, before/after text, a section path for source attribution, and a confidence score. It is built for legal, compliance, and contract management systems where traceability and schema compliance are non-negotiable.

The ideal user is an engineering team building a document version analysis pipeline. Required context includes two complete document versions with identifiable section structures—the prompt relies on section paths to attribute changes. You must provide a strict output schema, such as a JSON Schema definition, to enforce field types, required fields, and enum values for change types. The prompt expects documents where differences are textual and structural, not purely visual or formatting-based. If your documents lack section headings, numbered clauses, or other structural markers, the source attribution will degrade, and you should consider a layout-aware extraction step before invoking this prompt.

Do not use this prompt for free-text summarization, rendering visual diffs, or comparing documents where section structure is absent. It is also unsuitable for comparing more than two documents simultaneously—for multi-document reconciliation, use a dedicated cross-file inconsistency prompt. Avoid this prompt when the primary goal is generating a human-readable redline; the output is a JSON array meant for machine consumption, not a marked-up document. If your use case involves scanned PDFs with OCR noise, pre-process with an OCR-aware extraction prompt and validate text quality before comparison, as degraded text will produce false-positive changes and unreliable confidence scores. Always pair this prompt with a validation step that checks schema compliance, citation accuracy, and confidence thresholds before the output enters any downstream system.

This prompt template is designed to be dropped into a system that enforces JSON-only output and schema compliance. It instructs the model to compare two document versions and produce a machine-readable diff. The output includes the type of change, the exact before and after text, a precise section path for source attribution, and a confidence score. Before using this template, ensure you have extracted clean, plain-text representations of both document versions, as layout artifacts will degrade comparison accuracy.

textCopy
You are a document comparison engine. Your task is to compare the [PREVIOUS_VERSION] and [CURRENT_VERSION] of a document and output a structured JSON diff. You must attribute every change to its exact location using a section path.

Follow these rules strictly:
1. Identify all additions, deletions, and modifications.
2. For each change, extract the exact text from both versions. If text was added, the 'before' field must be an empty string. If text was deleted, the 'after' field must be an empty string.
3. Construct a 'section_path' for each change using the format "Document > Section > Subsection". Do not use page numbers.
4. Assign a 'confidence' score between 0.0 and 1.0. Use a lower score for ambiguous changes or formatting-only differences.
5. Classify the 'change_type' as one of: "addition", "deletion", "modification", or "formatting".
6. If there are no material differences, return an empty array.
7. Do not include any commentary outside the JSON object.

[PREVIOUS_VERSION]:
[INSERT_PREVIOUS_DOCUMENT_TEXT]

[CURRENT_VERSION]:
[INSERT_CURRENT_DOCUMENT_TEXT]

[OUTPUT_SCHEMA]:
{
  "diffs": [
    {
      "change_type": "modification",
      "before": "The quick brown fox",
      "after": "The quick red fox",
      "section_path": "Article I > Definitions > Section 1.2",
      "confidence": 0.98
    }
  ]
}

To adapt this prompt, replace the [INSERT_PREVIOUS_DOCUMENT_TEXT] and [INSERT_CURRENT_DOCUMENT_TEXT] placeholders with your pre-processed text. For high-stakes legal or compliance workflows, you should add a [CONSTRAINTS] section that explicitly defines what constitutes a 'material' change versus a formatting change. After receiving the output, validate the JSON against the provided schema and implement a secondary check that verifies each section_path actually exists in the source documents to catch hallucinated citations.

The structured diff prompt is not a standalone tool—it is one step in a document comparison pipeline. In production, you will call this prompt after extracting and normalizing text from both document versions, and before storing or displaying the diff results. The prompt expects pre-extracted text segments with section path metadata, not raw PDFs or scanned images. This means your pipeline must handle layout-aware extraction, OCR cleanup, and section hierarchy parsing upstream. The prompt's output—a JSON array of change objects with change_type, before_text, after_text, section_path, and confidence—must then pass through validation, deduplication, and citation accuracy checks before it reaches any downstream system or user interface.

Wire the prompt into your application with a validation-first architecture. After receiving the model's JSON response, run a schema validator that checks required fields, enum values for change_type (only added, removed, modified, moved, formatting_only), and confidence score ranges (0.0 to 1.0). Next, run a citation accuracy check: for each change object, verify that the before_text and after_text substrings actually appear at the claimed section_path in the source documents. This prevents hallucinated diffs where the model invents changes that do not exist in either document. If citation accuracy falls below a threshold (start with 95%), flag the entire diff for human review rather than silently accepting it. For high-risk domains like legal or compliance, add a human approval queue that surfaces low-confidence changes (confidence < 0.7) and changes where the before_text or after_text cannot be verified in the source documents.

Build retry logic around the model call itself. If the response fails JSON parsing, retry once with the same prompt plus the parse error message appended as a correction instruction. If the second attempt also fails, log the raw response and escalate. For formatting_only changes, apply a deduplication pass: if the model reports a formatting change at the same section path as a content change, keep only the content change and discard the formatting-only entry to avoid noise. Choose a model with strong structured output support—GPT-4o or Claude 3.5 Sonnet with JSON mode enabled—and set temperature=0 for deterministic diffs. Log every prompt call with the input document hashes, model version, raw response, validation results, and final accepted diff count. This trace data becomes essential when debugging false positives, missed changes, or format drift after a model upgrade.