Exhibit Identification and Extraction Prompt Template

This prompt is designed for legal engineering teams building document processing pipelines that must reliably identify, extract, and link exhibits within contracts, regulatory filings, and other structured legal documents. The primary job-to-be-done is automated exhibit boundary detection: finding where each exhibit starts and ends, extracting its label and title, and connecting it back to the referencing clause in the parent document. This is not a general-purpose PDF extraction prompt—it assumes the input is a legal document with conventional exhibit structures such as 'Exhibit A,' 'Schedule 1,' or 'Annex B' and that the output will feed into a downstream system for chunking, indexing, or contract review.

Use this prompt when your document pipeline needs to separate exhibits from the main body of a contract for independent processing, when you need to verify that all referenced exhibits are actually present in the document set, or when you need to build a navigable exhibit index for a document Q&A system. The ideal user is a developer or legal engineer who has already extracted text from PDFs or digital documents and needs structured exhibit metadata. Required context includes the full document text, any known exhibit naming conventions used by the organization or document type, and optionally a list of exhibit references extracted from the main body clauses. Do not use this prompt for documents without formal exhibit structures, for general-purpose table of contents extraction, or for documents where exhibits are inline sections rather than separate labeled attachments.

Before deploying this prompt in production, ensure you have a clear definition of what constitutes an exhibit boundary in your document corpus. Some documents use page breaks, others use centered labels, and still others use section numbering conventions. The prompt includes placeholders for [EXHIBIT_NAMING_CONVENTIONS] and [DOCUMENT_TYPE] to adapt to your specific domain. Always pair this prompt with validation checks that verify every extracted exhibit has a non-empty label, that exhibit boundaries don't overlap, and that exhibits referenced in the main body are accounted for in the extraction output. For high-stakes legal workflows, include a human review step for any exhibits flagged as ambiguous or where the extraction confidence falls below your threshold.

The prompt template below is designed to be copied directly into your prompt management system, IDE, or orchestration layer. It uses square-bracket placeholders for all variable inputs, constraints, and output format requirements. Before using it in production, replace each placeholder with the actual values for your document processing pipeline. The template assumes you have already extracted the full text of the contract or filing and can provide it as [DOCUMENT_TEXT]. If your pipeline processes documents page by page, you will need to assemble the full text before invoking this prompt, as exhibit boundaries often span multiple pages and cannot be reliably detected from isolated page chunks.

textCopy
You are a legal document structure analyst. Your task is to identify all exhibits, schedules, annexes, and attachments in the provided document text. For each exhibit found, you must determine its start and end boundaries, extract its label and title, and identify which clauses in the main document reference it.

## INPUT
[DOCUMENT_TEXT]

## CONSTRAINTS
- Only identify exhibits that are actually present in the document text. Do not invent exhibits that are referenced but not included.
- An exhibit begins at its title or label line (e.g., 'Exhibit A', 'Schedule 1', 'Annex B') and ends immediately before the next exhibit begins or at the end of the document.
- Distinguish between inline references to exhibits (e.g., 'as set forth in Exhibit A') and the actual start of an exhibit section. Only mark the latter as an exhibit boundary.
- If an exhibit is referenced in the document but its content is not present, list it under 'referenced_but_missing' with the referencing clause locations.
- Multi-page exhibits must be captured as a single continuous span from start to end.
- If exhibit boundaries are ambiguous due to poor formatting or missing labels, flag the exhibit with confidence='low' and explain the ambiguity.

## OUTPUT_SCHEMA
Return a valid JSON object with this exact structure:
{
  "exhibits": [
    {
      "label": "string (e.g., 'Exhibit A', 'Schedule 2.1')",
      "title": "string or null (the descriptive title if present)",
      "start_char": integer (character offset where exhibit content begins),
      "end_char": integer (character offset where exhibit content ends),
      "referencing_clauses": [
        {
          "clause_text": "string (the sentence or clause that references this exhibit)",
          "location": "string (section number or paragraph reference where the clause appears)",
          "start_char": integer
        }
      ],
      "confidence": "high|medium|low",
      "notes": "string or null (explain any boundary ambiguity or extraction issues)"
    }
  ],
  "referenced_but_missing": [
    {
      "label": "string",
      "referencing_clauses": [
        {
          "clause_text": "string",
          "location": "string",
          "start_char": integer
        }
      ]
    }
  ]
}

## EXAMPLES
[EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

## INSTRUCTIONS
1. Scan the full document text for exhibit labels and section headers.
2. For each exhibit found, locate its start boundary (the label line) and end boundary (next exhibit start or document end).
3. Search the main document body for clauses that reference each exhibit by label.
4. If [RISK_LEVEL] is 'high', flag any exhibit with confidence below 'high' for human review.
5. Output only the JSON object. Do not include any explanatory text outside the JSON.

To adapt this template for your pipeline, start by replacing [DOCUMENT_TEXT] with the full extracted text from your PDF or document parser. The [EXAMPLES] placeholder should be populated with one or two few-shot demonstrations showing correct exhibit extraction from documents similar to yours—this is especially important if your documents use non-standard labeling conventions like Roman numerals or descriptive titles without explicit 'Exhibit' prefixes. The [RISK_LEVEL] placeholder accepts 'low', 'medium', or 'high' and controls whether the prompt requests human review flags. For production legal workflows, set this to 'high' and ensure your application layer routes low-confidence extractions to a review queue. The output schema uses character offsets rather than page numbers because character offsets are more reliable across different text extraction methods; your application should map these back to page and line numbers using your document's text position metadata. Before deploying, validate that your model reliably produces the exact JSON schema specified—schema drift is the most common failure mode for structured extraction prompts.

The exhibit extraction prompt is rarely a standalone call. It sits inside a document processing pipeline that has already identified the main contract body and needs to isolate exhibits for separate downstream processing, indexing, or summarization. The harness must handle multi-page documents, exhibits that span page breaks, exhibits referenced but not physically present, and inline exhibits that lack clear boundary markers. Before calling the prompt, the application layer should split the document into manageable chunks that preserve page boundary metadata, because the model needs page references to report exhibit locations accurately.

Wire the prompt as a structured output call with a strict JSON schema. Require the model to return an array of exhibit objects, each containing exhibit_label (string), exhibit_title (string or null), start_page (integer), end_page (integer), referencing_clause (string or null), and present_in_document (boolean). Validate the output immediately: check that start_page is less than or equal to end_page, that page ranges don't overlap for exhibits marked as present, and that every present_in_document: false exhibit has a non-null referencing_clause. If validation fails, retry once with the validation errors appended to the prompt as [CONSTRAINTS]. If the retry also fails, route the document to a human review queue with the partial output and error details attached. Log every extraction attempt with the document ID, model version, prompt version, validation result, and retry count for observability.

For documents exceeding the model's context window, implement a two-pass architecture. First, run a lightweight classification pass over each page or chunk to detect exhibit start candidates using a simpler prompt or heuristic (e.g., regex for 'Exhibit', 'Schedule', 'Annex' followed by a label). Second, assemble the candidate pages plus surrounding context into a focused extraction window and run the full exhibit identification prompt only on that subset. This avoids sending entire 200-page filings through the prompt while still giving the model enough context to determine exhibit boundaries and titles. Store the extracted exhibit metadata in your document index so downstream retrieval and Q&A systems can scope searches to specific exhibits when users ask about them.

Model choice matters here. Use a model with strong instruction-following and structured output support for the primary extraction call. Claude 3.5 Sonnet or GPT-4o are good defaults for this task because exhibit boundary detection requires reasoning about document structure, cross-references, and legal formatting conventions. Avoid smaller or older models that struggle with multi-page spatial reasoning. If cost is a concern, use a smaller model for the candidate detection pass and reserve the larger model only for the focused extraction window. Always set temperature=0 or very low to get consistent boundary detection across repeated runs on the same document.

Build eval assertions into your test suite before shipping. At minimum, test: (1) a document with sequentially labeled exhibits all present, (2) a document where an exhibit is referenced but not attached, (3) a document with an inline exhibit that starts mid-page without a page break, (4) a multi-page exhibit spanning three or more pages, and (5) a document with no exhibits at all. For each test case, assert the exact exhibit count, correct label extraction, and accurate page ranges. Run these evals on every prompt change and on every model version upgrade. When an eval fails, inspect whether the prompt needs adjustment or whether the new model has different behavior around boundary detection.