Cross-File Reference Validation Prompt

This prompt is for document quality teams, legal engineers, and compliance analysts who need to validate cross-references across a set of related documents. It detects broken references where a target section, exhibit, or clause does not exist, identifies circular dependencies where Document A points to Document B which points back to Document A without resolution, and flags incorrect section pointers where a reference cites the wrong section number or title. Use this prompt when you have a collection of documents that reference each other and you need a structured audit of every reference's validity before the document set is finalized, filed, or executed.

The ideal user has access to the full text of all referenced documents, with consistent section numbering, exhibit labels, or clause identifiers that the model can use to resolve targets. The prompt expects documents to be provided inline or via clear identifiers that map to retrievable content. It works best when references follow predictable patterns—such as 'See Section 4.2(a)' or 'as defined in Exhibit C'—and when the document set is bounded rather than an open-ended corpus. You should not use this prompt on a single document with internal cross-references alone; it is designed for cross-file validation where the target may reside in a different document entirely.

This is not a general document comparison prompt. It does not identify semantic differences, redlines, or conflicting clauses. It strictly validates the mechanical correctness of cross-document pointers. Do not use it when you need to reconcile contradictory terms, detect amendments, or compare version changes. For those tasks, use the Multi-Document Clause Reconciliation Prompt, Amendment Detection Prompt, or Redline Comparison Prompt instead. The output is a structured audit of reference validity, not a legal analysis of the referenced content.

Before running this prompt, ensure that all documents in the set are finalized enough that section numbering and exhibit labels are stable. Running reference validation on draft documents with shifting structure will produce noise. Also confirm that you have a complete inventory of expected cross-references—the prompt can validate references it finds, but it cannot guarantee it found every reference. For high-stakes filings or executions, pair this prompt's output with a manual review of the reference audit before signing. The next section provides the copy-ready prompt template you can adapt to your document set.

This prompt template is designed to be copied directly into your prompt layer and adapted for your specific document validation workflow. It accepts a set of documents and a list of cross-references to validate, then produces structured findings with source citations. Replace each square-bracket placeholder with real data before sending to the model. The template assumes you have already extracted cross-references from your documents using a separate extraction step—this prompt focuses exclusively on validation logic.

textCopy
You are a document quality validation assistant. Your task is to validate cross-references across a set of documents and identify broken references, circular dependencies, and incorrect section pointers.

## INPUT DOCUMENTS
[DOCUMENTS]
<!-- Provide each document as a structured object with:
     - document_id: unique identifier
     - title: document title
     - sections: array of section objects with section_id, section_number, title, and content
     - metadata: version, effective_date, document_type -->

## CROSS-REFERENCES TO VALIDATE
[REFERENCES]
<!-- Provide each reference as a structured object with:
     - reference_id: unique identifier
     - source_document_id: document containing the reference
     - source_section_id: section where the reference appears
     - reference_text: the exact text of the reference
     - target_document_id: document being referenced (if specified)
     - target_section_id: section being referenced (if specified)
     - target_section_number: section number being referenced (if specified)
     - reference_type: one of [internal_cross_reference, external_document_reference, definition_reference, exhibit_reference, schedule_reference] -->

## OUTPUT SCHEMA
[OUTPUT_SCHEMA]
<!-- Expected JSON structure:
{
  "validation_results": [
    {
      "reference_id": "string",
      "status": "valid | broken | circular | ambiguous | unverifiable",
      "source_location": {
        "document_id": "string",
        "section_id": "string",
        "reference_text": "string"
      },
      "target_location": {
        "document_id": "string | null",
        "section_id": "string | null",
        "section_number": "string | null",
        "resolved_title": "string | null"
      },
      "finding": "string explaining the validation result",
      "severity": "critical | high | medium | low | info",
      "recommendation": "string with suggested fix or next step",
      "circular_chain": ["string"] // only populated for circular references
    }
  ],
  "summary": {
    "total_references": 0,
    "valid": 0,
    "broken": 0,
    "circular": 0,
    "ambiguous": 0,
    "unverifiable": 0
  }
} -->

## CONSTRAINTS
[CONSTRAINTS]
<!-- Example constraints:
     - Only flag a reference as broken if the target document or section definitively does not exist in the provided document set
     - Mark as unverifiable if the target document is referenced but not included in the input set
     - Detect circular references by tracing reference chains across documents (A references B, B references A)
     - For ambiguous references where multiple potential targets exist, list all candidates and mark as ambiguous
     - Do not hallucinate section content or document structure not present in the input
     - Cite exact source section IDs and document IDs in every finding
     - If a reference uses a section number that does not match any section in the target document, flag as broken even if a section with similar content exists -->

## EXAMPLES
[EXAMPLES]
<!-- Provide 2-4 few-shot examples showing:
     - A valid cross-reference with correct resolution
     - A broken reference with non-existent target section
     - A circular reference chain across documents
     - An ambiguous reference with multiple possible targets -->

## RISK LEVEL
[RISK_LEVEL]
<!-- Set to one of: low, medium, high, critical
     - Critical/high: require human review of all findings before action
     - Medium: require human review of broken and circular findings only
     - Low: automated remediation acceptable for non-critical findings -->

## INSTRUCTIONS
1. Load all input documents and build an index of document IDs, section IDs, and section numbers.
2. For each cross-reference, attempt to resolve the target within the provided document set.
3. Classify each reference using the status values defined in the output schema.
4. For circular references, trace and report the full circular chain.
5. Assign severity based on: critical (broken reference in executed agreement), high (broken reference in draft), medium (ambiguous reference), low (unverifiable external reference), info (valid reference).
6. Output ONLY valid JSON matching the output schema. No explanatory text outside the JSON.

After copying this template, adapt the constraints to match your document domain. For legal documents, add constraints about governing law sections and defined terms. For regulatory filings, add constraints about item-level citations and amendment tracking. The examples placeholder is critical for performance—include at least two examples showing broken references and one showing a circular dependency. If your document set is large, consider pre-indexing sections and passing only relevant document subsets to reduce context window pressure. Always run validation against a golden dataset of known broken and valid references before deploying to production.

The Cross-File Reference Validation Prompt is designed to operate as a post-extraction validation step in a document processing pipeline, not as a standalone tool. Before this prompt runs, you must already have extracted the document structure (headings, section numbers, page numbers) and any explicit cross-references (e.g., 'see Section 4.2(a)', 'as defined in Exhibit B', 'pursuant to the Master Agreement dated...') from each document in the set. The prompt expects these structured inputs, not raw PDFs. This separation of concerns—extraction first, validation second—keeps each prompt focused and testable. If you attempt to feed raw documents directly into this prompt, you will get unreliable results because the model will spend its capacity on extraction rather than validation, and you lose the ability to unit-test the extraction layer independently.

Pipeline integration pattern: Wire this prompt as a validation node that receives a JSON payload containing the document set's structural metadata and extracted references. The node should: (1) run the prompt against the structured input, (2) parse the JSON output into a list of reference issues, (3) run a schema validator that checks required fields (reference_text, source_document, source_location, target_document, target_location, issue_type, severity, evidence), (4) apply a confidence threshold—discard or flag for review any issue with confidence below 0.7, and (5) route severity: critical issues to a human review queue while auto-accepting severity: info items. For model choice, use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and enable JSON mode or structured output constraints. Set temperature to 0 or near-zero to maximize deterministic reference resolution. If your document set exceeds the model's context window, pre-filter by clustering documents that share explicit cross-reference links and run the prompt per cluster, then deduplicate results.

Retry and failure handling: If the output fails schema validation, retry once with the validation errors appended to the prompt as [PREVIOUS_ERRORS]. If the second attempt also fails, log the failure and route the document cluster to a human reviewer with the partial output attached. Do not retry more than twice—beyond that, the input is likely malformed or the reference structure is too ambiguous for automated resolution. Evaluation and monitoring: Before deploying, build a golden test set of 20-50 document clusters with known cross-reference issues (broken links, circular refs, incorrect pointers) and run the prompt against them. Measure precision (did flagged issues actually exist?) and recall (did the prompt miss any known issues?). Track these metrics per document type and per issue_type category. In production, log every validation run with the input hash, output issue count, schema validation pass/fail, and human review outcomes. Use these logs to detect drift—if the rate of human-overridden decisions rises above 10%, re-evaluate the prompt or the extraction layer upstream. What to avoid: Do not use this prompt for documents where cross-references are implicit or narrative ('the aforementioned provision') without first expanding those references in the extraction layer. Do not skip the schema validator—unstructured issue descriptions will break downstream routing and reporting. And do not treat the prompt's output as ground truth for high-stakes legal or compliance decisions without human review of critical and high severity findings.