Table-of-Contents Extraction Prompt for Long Documents

This prompt is for document pipeline engineers who need to extract a structured, hierarchical table of contents (TOC) from long documents—PDFs, reports, legal filings, technical manuals, or regulatory submissions—where the TOC carries the document's logical skeleton. The job-to-be-done is producing a navigable JSON tree of section titles, heading levels, page numbers, and parent-child relationships that can drive navigation UIs, search indexes, or downstream chunking strategies. The ideal user is an integration engineer or document intelligence developer building a production ingestion pipeline where TOC accuracy directly affects downstream retrieval and user experience.

Use this prompt when the source document has an explicit table of contents section or when section headings are consistently styled and numbered. It works best with documents that follow predictable heading conventions (e.g., '1.', '1.1', 'Chapter 3', 'Appendix A'). Do not use this prompt for documents without any heading structure, for image-only PDFs where OCR hasn't been applied, or for extracting body content itself—this prompt targets the TOC as a structural map, not the full text. The prompt assumes you've already extracted the TOC pages or the full document text and can provide it as [DOCUMENT_TEXT]. For multi-column layouts or documents where the TOC spans non-contiguous pages, pair this with the Reading Order Recovery Prompt first.

The prompt produces a JSON array of TOC entries, each with a title string, a hierarchical level integer, a page number, and an optional parent reference. The harness should validate that page numbers are monotonically increasing within each section, that heading levels don't skip (e.g., jumping from level 1 to level 3 without a level 2), and that the total entry count is plausible for the document length. For high-stakes documents like legal filings or regulatory submissions, add a human review step that compares the extracted TOC against the original document's stated TOC. The next section provides the copy-ready template with placeholders you can adapt to your document format and output schema.

The following prompt template is designed to be dropped into your document processing pipeline. It instructs the model to extract a hierarchical table of contents (TOC) from the provided document text, returning a navigable JSON tree. The template uses square-bracket placeholders for all dynamic inputs, allowing you to swap in the document content, specify the desired output schema, and add any domain-specific constraints without rewriting the core instruction.

textCopy
You are a precise document structure extraction engine.
Your task is to extract the table of contents from the provided document.

INPUT DOCUMENT:
---
[DOCUMENT_TEXT]
---

INSTRUCTIONS:
1. Identify all entries that constitute the document's table of contents, including section headings, subheadings, and any listed front-matter or back-matter items (e.g., Preface, Appendix, Index).
2. For each entry, determine its hierarchical level. The top-level sections are level 1, their direct subsections are level 2, and so on.
3. Extract the exact title text for each entry.
4. If a page number is provided for an entry, capture it as an integer. If no page number is present, use `null`.
5. Reconstruct the full hierarchy as a nested JSON tree structure.

OUTPUT_SCHEMA:
```json
[OUTPUT_SCHEMA]

CONSTRAINTS:

• Do not infer or hallucinate entries that are not explicitly present in the text.
• Preserve the original casing and punctuation of titles.
• If the document contains multiple conflicting TOCs (e.g., a brief overview and a detailed one), prioritize the most detailed one and note the conflict in a [WARNING] comment within the output.
• If no TOC is found, return an empty list [].
• [CONSTRAINTS]

EXAMPLES OF GOOD OUTPUT: [EXAMPLES]

Now, extract the table of contents.

To adapt this template, start by replacing [DOCUMENT_TEXT] with the full text of your document. The [OUTPUT_SCHEMA] placeholder is critical for downstream integration; replace it with the exact JSON schema you expect, for example, a recursive structure with title, page, level, and children fields. Use the [CONSTRAINTS] placeholder to inject domain-specific rules, such as ignoring page numbers in a legal document's table of authorities or handling documents where sections are numbered with Roman numerals. The [EXAMPLES] placeholder should be used to provide one or two few-shot examples of a correctly parsed TOC from a similar document, which dramatically improves accuracy on complex layouts. After generating the output, always validate it against your schema and run a consistency check to ensure the extracted page numbers are monotonically increasing and that no section titles are duplicated at the same level without a clear distinguishing context.

The TOC extraction prompt is rarely a standalone call. In production, it sits inside a document processing pipeline that first extracts the raw text (and optionally layout metadata) from a PDF or other format, then passes a windowed segment containing the table of contents to the LLM. The prompt expects a chunk of text that includes the TOC, but it does not need the entire document body. A common pattern is to extract the first 5–15 pages of a long document, or to use a layout-aware parser to isolate the TOC section before sending it to the model. This reduces token cost and prevents the model from confusing body-text headings with TOC entries.

Validation and repair loop. The prompt output is a JSON array of TOC entries with level, title, and page fields. Before accepting the result, run a structural validator that checks: (1) the root entry has level: 1, (2) levels increment by at most 1 between consecutive entries (no skipped levels), (3) page numbers are non-decreasing, and (4) every entry has a non-empty title. If validation fails, feed the malformed output and the specific validator error back to the model in a repair prompt: 'The previous output failed validation with error: [ERROR]. The TOC must have a single level-1 root, no skipped nesting levels, and non-decreasing page numbers. Return the corrected JSON.' Allow up to 2 repair retries before flagging for human review. Log every repair attempt with the validator error and the model's correction for observability.

TOC-to-body consistency check. The most dangerous failure mode is a TOC that looks structurally valid but does not match the actual document body. After extraction, run a consistency harness that samples 5–10 TOC entries, searches for the corresponding section titles in the document body text, and verifies that the section appears near the claimed page number. Use fuzzy string matching (e.g., Levenshtein distance with a threshold of 0.85) to handle minor OCR or formatting differences. Flag any entry where the title cannot be found within ±1 page of the claimed location. If more than 10% of sampled entries fail, reject the entire TOC and escalate for manual review. This check catches hallucinated entries, page-offset errors from Roman-numeral front matter, and misaligned PDF text extraction.

Model choice and latency budget. For most TOC extraction tasks, a mid-tier model (e.g., GPT-4o-mini, Claude 3.5 Haiku, or a fine-tuned open-weight model) provides sufficient accuracy at low latency and cost. Reserve larger models for documents with complex multi-level numbering schemes, legal clause references, or non-English TOCs. Set a latency budget of 3–5 seconds for the initial extraction call, and 2 seconds per repair retry. If the document pipeline processes hundreds of documents per hour, batch TOC extraction calls asynchronously and use a model router that falls back to a faster model when the primary model exceeds the latency budget.

Integration with downstream systems. The validated TOC JSON should be stored alongside the document record in your search index or document store. Use the page field to build navigation links in a document viewer, and the level and title fields to render an expandable sidebar tree. If your system supports section-level retrieval for RAG, use the TOC entries as chunk boundary hints: each TOC entry defines a logical section start, and you can chunk the document body from one TOC entry's page to the next. This produces semantically coherent chunks that align with the document's own structure. Avoid using the TOC as the sole source of truth for document structure without the consistency check described above—always verify against the body.