Nested Hierarchy Extraction Prompt for Document Outlines

This prompt is designed for a specific job: converting a flat text representation of a document's outline into a structured, tree-based JSON object. The ideal user is a document intelligence engineer or a legal/technical documentation specialist who already has extracted text from a PDF, DOCX, or similar format and needs to reconstruct the logical section hierarchy. The core value is turning a linear sequence of headings like '1. Introduction', '1.1 Scope', '2. Methods' into a navigable parent-child structure that preserves numbering schemes, heading levels, and cross-reference targets. This structured output is essential for building search indexes, document viewers with collapsible navigation, or compliance review systems where the relationship between a clause and its sub-clauses carries legal or technical meaning.

You should use this prompt when the input text contains a clear, distinguishable heading structure through numbering (e.g., '3.2.1'), consistent indentation, or explicit markup like Markdown headers (#, ##). The prompt assumes that heading levels are inferable from these textual cues alone; it does not perform layout analysis on a rendered page. A concrete implementation would involve feeding the raw text of a contract's table of contents or a technical specification's outline into the prompt, with a constraint that the output must conform to a specific JSON schema where each node has id, title, level, number, and children fields. The prompt is not suitable for documents where headings are only visually distinct (e.g., bold and centered text without numbering) unless that visual formatting has been converted into explicit text markers during the extraction phase.

Avoid using this prompt when the primary challenge is page layout analysis, such as detecting columns, associating captions with figures, or extracting tables. For those tasks, use a dedicated layout extraction or table extraction prompt. Similarly, if you only need a flat list of section titles without parent-child relationships, a simpler extraction prompt will be more cost-effective and less prone to hallucinating a hierarchy where none exists. Before deploying this prompt, you must implement a validation harness that checks for common structural failures: broken numbering sequences (e.g., jumping from '2.1' to '2.3'), orphaned subheadings that lack a parent, and circular references in the output tree. For high-stakes legal or compliance workflows, always include a human review step to verify the extracted hierarchy against the original document before it is used in a production system.

This prompt template is designed to extract the full section hierarchy from a document outline, preserving the original numbering scheme, heading levels, and parent-child relationships. It produces a tree-structured JSON object where each node represents a section with its heading, level, numbering, children, and any cross-references detected within the section body. The template is built for legal and technical documentation teams who need reliable structure extraction before downstream processing, indexing, or navigation tree generation.

textCopy
You are a document structure extraction system. Your task is to extract the nested section hierarchy from the provided document text and return a tree-structured JSON object.

## INPUT
[INPUT]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "document_title": "string or null",
  "sections": [
    {
      "id": "unique-section-id",
      "heading": "Section heading text exactly as written",
      "level": integer (1 for top-level, 2 for sub-section, etc.),
      "numbering": "original numbering string, e.g., '1.2.3' or 'Article IV'",
      "page_reference": "page or location indicator if present, else null",
      "body_summary": "brief summary of section content if body text is present, else null",
      "cross_references": [
        {
          "target": "referenced section number or identifier",
          "reference_type": "see|refers_to|amends|subject_to|notwithstanding|other",
          "context": "surrounding sentence fragment containing the reference"
        }
      ],
      "children": []
    }
  ],
  "warnings": []
}

## CONSTRAINTS
[CONSTRAINTS]

## INSTRUCTIONS
1. Preserve the original numbering scheme exactly as it appears in the text. Do not renumber or normalize.
2. Determine heading levels based on numbering depth, indentation, and formatting cues in the text. If a section has no children, its children array must be empty.
3. Detect cross-references within section body text, including phrases like "see Section X", "as defined in Y", "subject to Z", "notwithstanding A", and similar reference language.
4. If a section number appears to skip a level (e.g., jumping from 1.1 to 1.3 without 1.2), flag it in the warnings array at the root level with the specific sections involved.
5. If a subheading appears without a parent section that matches its numbering prefix, flag it as an orphaned subheading in the warnings array.
6. Do not invent sections that are not present in the text. Only extract what is explicitly provided.
7. If the document has no discernible hierarchy, return a single section with the full text as the heading and an empty children array.

## EXAMPLES
[EXAMPLES]

## OUTPUT
Return only the JSON object. No markdown fences, no commentary.

To adapt this template, replace the square-bracket placeholders with your specific requirements. The [INPUT] placeholder should contain the full document text or outline to be processed. The [CONSTRAINTS] placeholder allows you to add domain-specific rules, such as maximum nesting depth, specific numbering patterns to recognize (e.g., Roman numerals for legal documents), or custom cross-reference patterns relevant to your document type. The [EXAMPLES] placeholder should include one or two few-shot examples showing the expected output for sample inputs, which significantly improves accuracy for unusual numbering schemes or deeply nested structures.

Before deploying this prompt into a production pipeline, implement validation checks on the output JSON. Verify that every child section's numbering prefix matches its parent's numbering, that no sections are duplicated, and that the warnings array captures real anomalies rather than false positives. For high-stakes document processing—such as legal contracts or regulatory filings—route outputs with non-empty warnings arrays to human review. Test the prompt against documents with known broken numbering sequences, orphaned subheadings, and cross-reference chains to ensure the extraction logic handles edge cases gracefully rather than silently producing incorrect hierarchies.

The hierarchy extraction prompt is designed to be called after text extraction and before downstream indexing or navigation systems. In a production pipeline, the raw text from a PDF parser or OCR engine is fed into the prompt, and the resulting JSON tree must be validated before it can be trusted by a table of contents generator, a document viewer sidebar, or a search index. The prompt alone is not enough—you need a harness that catches malformed JSON, schema violations, and logically inconsistent hierarchies before they corrupt downstream systems.

Wrap the model call in a validation layer that checks the output JSON against the expected schema. The schema should enforce the presence of required fields like sections, heading_level, numbering, and children, and it should verify that heading_level values are integers that increment or decrement by no more than one level at a time. For production deployments, implement a retry loop with a maximum of 3 attempts if the output fails JSON parsing or schema validation. On the second and third retries, append the specific validation error to the prompt as additional context—for example, 'Previous output failed validation: heading_level jumped from 2 to 4 without a level-3 parent.' This gives the model a concrete signal to self-correct rather than guessing. Log every extraction attempt with the document identifier, model version, prompt version, and validation result for audit trails. If the warnings array in the output contains broken numbering sequences or orphaned subheadings, route the document to a human review queue rather than silently ingesting potentially corrupted hierarchy data.

For documents exceeding the model context window, split the document at major section boundaries—ideally at heading level 1 or 2 transitions—process each part independently, and merge the resulting trees by matching section numbering at the split points. This merge step requires a reconciliation function that aligns overlapping sections and resolves numbering conflicts. Store the extracted hierarchy alongside the source document with a timestamp and model version for traceability. When choosing a model, prefer one with strong JSON mode and long-context support; smaller models may struggle with deeply nested legal or technical outlines. Avoid deploying this prompt without a human review queue for documents flagged with structural warnings—silent ingestion of broken hierarchies will degrade search relevance and navigation accuracy over time.