Footnote and Endnote Extraction Prompt

This prompt is designed for document intelligence engineers and legal or academic data pipeline operators who need to extract footnotes, endnotes, and their corresponding in-text anchors from structured documents such as contracts, court filings, academic papers, and regulatory submissions. The core job-to-be-done is producing a machine-readable, linked mapping of note-body pairs with page locations and cross-reference integrity checks. The ideal user has access to pre-parsed text with page metadata and needs structured JSON output for downstream ingestion into a document database, search index, or review platform.

Use this prompt when the document's logical structure is already recovered—meaning you have clean text blocks with page numbers—and you need to isolate the note apparatus from the body text. It is appropriate for single-document processing where the note format follows standard conventions (superscript numerals, bracketed numbers, or symbolic references). The prompt expects [INPUT] to contain the full document text with page markers, and it will produce a JSON array of note objects, each containing the anchor text span, the note body, the page location of both, and a cross-reference status flag. Do not use this prompt for handwritten notes, scanned documents without OCR, or documents where notes are inline parentheticals rather than separated footnotes or endnotes.

This prompt is not a substitute for a full document layout parser. It assumes that text has already been linearized and that page boundaries are known. If your document has multi-column layouts, sidebars, or complex floating elements, you should first apply a reading-order recovery prompt to establish a reliable text sequence. Additionally, this prompt does not handle image-based notes or notes embedded in tables—those require a multimodal extraction approach. For high-stakes legal or regulatory use cases, always pair this prompt with a validation harness that checks for orphaned notes (note bodies without anchors) and broken references (anchors pointing to non-existent notes). Human review should be triggered when the cross-reference integrity check fails or when confidence scores fall below your operational threshold.

This prompt template is designed to be dropped into a document processing pipeline where the input is a single, plain-text representation of a document containing footnotes or endnotes. It instructs the model to identify every note, locate its corresponding anchor in the body text, and return a structured array of linked pairs. The template uses square-bracket placeholders for all variable inputs, allowing you to adapt it to different document formats, output schemas, and risk tolerances without rewriting the core instruction logic.

textCopy
You are a precise document structure extraction engine. Your task is to extract all footnotes and endnotes from the provided document text, link each note to its corresponding anchor in the body text, and return the results in a strict JSON format.

## INPUT
Document text:
[INPUT_TEXT]

## OUTPUT SCHEMA
Return a single JSON object with a key "notes" containing an array of note objects. Each note object must have the following fields:
- "note_id": string, a unique identifier for the note (e.g., "fn1", "en12").
- "note_type": string, either "footnote" or "endnote".
- "note_text": string, the full text of the note, cleaned of any leading markers.
- "anchor_text": string, the exact text span in the body that references this note (e.g., "¹", "[1]", "see note 3").
- "anchor_context": string, a 100-character window of body text surrounding the anchor for verification.
- "page_number": integer or null, the page number where the note appears, if detectable from the text.
- "cross_references": array of strings, a list of other note_ids referenced within this note's text.
- "confidence": number between 0.0 and 1.0, your confidence that the anchor-note pairing is correct.

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

## INSTRUCTIONS
1. Scan the entire document to identify all footnote and endnote markers in the body text and the notes themselves.
2. For each note, find its exact anchor in the body text. If an anchor cannot be found, set "anchor_text" to null and "confidence" to 0.0.
3. If a note references another note, list its ID in "cross_references".
4. If the document contains both footnotes and endnotes, distinguish them accurately.
5. Do not invent notes or anchors. If the text is ambiguous, set "confidence" below 0.5 and note the ambiguity in a separate "warnings" array at the top level of the JSON output.

To adapt this template, replace the placeholders with your specific requirements. For [CONSTRAINTS], add rules like "Ignore notes in headers and footers" or "Treat roman numeral markers as endnotes." For [EXAMPLES], provide one or two few-shot demonstrations of the exact input-output mapping you expect, especially for edge cases like in-text citations that are not notes. The [RISK_LEVEL] placeholder should be set to "high" for legal or regulatory documents, which will trigger a post-processing validation step in your harness to check for orphaned notes and broken cross-references before the output is accepted.

The footnote and endnote extraction prompt is designed to be called after the main body text has been extracted and segmented by page. In a production pipeline, you should pass the full document text with page markers as [INPUT] and a strict JSON schema as [OUTPUT_SCHEMA]. The model must return a list of note objects, each containing the note text, its anchor symbol or number, the page where the note appears, and the page and approximate span of the body-text anchor. This output is not the final product—it is a structured intermediate payload that must be validated before ingestion into a document index or review system.

Wire the prompt into your application with a post-processing validator that checks for three critical failure modes: orphaned notes (notes with no matching body anchor), broken cross-references (body anchors that point to non-existent notes), and duplicate anchor symbols on the same page. Implement a retry loop that re-submits failed pages with the validator's error messages appended as [CONSTRAINTS]. For high-stakes legal or regulatory documents, route any page with unresolved validation errors to a human review queue. Log every extraction run with the document ID, page range, model version, prompt version, validator results, and human-review decisions. This audit trail is essential for compliance teams who need to prove extraction completeness.

Model choice matters here. Use a model with strong instruction-following and long-context handling, such as GPT-4o or Claude 3.5 Sonnet, because footnote sections often span many pages and the model must maintain anchor-note linkage across long distances. Avoid small or local models for documents exceeding 50 pages unless you chunk the document into overlapping sections and reconcile the outputs with a deduplication step. Do not rely on the prompt alone for cross-reference integrity—always run the validator. The prompt is the extraction engine; the harness is the safety net.