How to Extract Definitions and References from Legal and Technical Documents

Extraction is a relationship problem, not a text problem

A document search index can tell you that a phrase occurs on page 47. That is useful, but it cannot reliably answer questions such as:

• What does “Authorized User” mean in this agreement?
• Does that meaning apply to the entire document, one schedule, or one section?
• Does “ISO 27001:2022” appear as a requirement or merely as background reading?
• Which edition of a cited standard was intended?
• Can a reviewer go directly from an extracted record back to the exact source passage?

To extract definitions and references from documents reliably, treat the output as a graph of typed, reviewable relationships. A definition links a term to meaning within a scope. A reference links source text to a cited work or cited unit. Both need durable evidence: document identity, version, page or clause, source text, and preferably a character range or bounding box.

This approach matters in legal, compliance, and technical-support systems because the same words can carry different meanings across clauses, annexes, and document versions.

1. Start with document forensics

Do not apply regular expressions to a PDF until you know what kind of PDF it is. A file may contain selectable text, a tagged logical structure, page images that need OCR, or some mixture of all three.

Tagged PDF can expose logical structure intended to support extraction and reuse, but its presence is not guaranteed. The PDF specification describes that structural framework, while the practical quality of a particular file still needs verification. PDF Reference, version 1.7

Build an intake record before semantic extraction:

{
  "documentId": "sha256:…",
  "sourceFilename": "security-addendum.pdf",
  "pageCount": 28,
  "sourceFormat": "pdf",
  "textMode": "native | ocr | mixed",
  "structureMode": "tagged | untagged | unknown",
  "acquiredAt": "2026-10-09T12:00:00Z"
}

Triage the text layer

For each page, test whether extracted text is plausible:

1. Measure character count and the proportion of readable words.
2. Look for recurring headers, footers, page numbers, and hyphenation artifacts.
3. Compare text order with visual order on a sample of difficult pages.
4. Mark image-only or corrupted pages for OCR.
5. Retain the original file even after creating an OCR derivative.

Reading order is especially important for scanned, multi-column, and table-heavy files. OCR guidance from the Library of Congress specifies that OCR text should follow natural reading order. NDNP OCR Profile If your pipeline gets that order wrong, a definition in the left column can be joined to a citation in the right column, creating a relationship that never existed.

Preserve layout, not just strings

A plain text blob discards the evidence needed to diagnose extraction errors. Prefer an intermediate representation that retains words, page numbers, bounding boxes, font cues, and reading-order indices. For example, pdfplumber exposes coordinates for words and characters, layout-aware extraction, text search results with bounding boxes, and table extraction features. pdfplumber README

Keep headers, footnotes, tables, and body text as separate regions until you have a reason to merge them. A superscripted footnote may qualify a definition; a table cell may define a variable; a running header may look like a section title but should not become one.

2. Build a structural view before detecting terms

Definitions and citations are easier to interpret after reconstructing a lightweight document outline. Identify headings, numbering, lists, annexes, tables, notes, and footnotes. Then assign every extracted token to its nearest structural container.

Useful structural signals include:

• numbered headings such as 2, 2.1, or Section 4.3;
• heading typography and whitespace;
• repeated page-level regions, which often indicate headers and footers;
• label-value rows in tables;
• section titles such as “Definitions,” “Terms and Definitions,” “Normative References,” and “Bibliography.”

Do not blindly trust PDF tags. Structure tagging is optional and is implemented inconsistently across real files, so it should be treated as corroborating evidence rather than an unquestioned source of truth. pdfplumber Structure Documentation

A practical DocumentNode can hold a stable section path:

{
  "nodeId": "sec-3-2",
  "kind": "section",
  "label": "3.2",
  "title": "Access Controls",
  "pageStart": 7,
  "pageEnd": 9,
  "parentId": "sec-3"
}

This structure is what lets a later definition record say not merely “page 8,” but “Section 3.2, under Annex A.”

3. Detect definitions, then determine their scope

Definition detection should combine local language patterns with document structure. High-value candidate patterns include:

• “Term” means …
• “Term” shall mean …
• Term: … in a dedicated definitions table
• For purposes of this Agreement, …
• as defined in Section 1.2
• a term followed by an em dash and explanatory text

These are candidates, not facts. A phrase such as “definition means” in ordinary prose should not become a term record. Require supporting signals such as quotation marks, title case, bold styling, a dedicated definition section, a colon-delimited table row, or a controlled cross-reference.

Scope is part of the definition

A term-to-text map is insufficient. Legal definitions can be global, local, overridden, conditional, or explicitly imported from elsewhere. The Federal Acquisition Regulation illustrates this distinction: its general definitions can apply throughout the regulation, while definitions elsewhere may apply only in a narrower part, subpart, or section, subject to context and more specific provisions. Federal Acquisition Regulation, Part 2

Represent scope explicitly:

{
  "recordType": "definition",
  "term": "Authorized User",
  "definitionText": "an individual permitted to access the Service…",
  "scope": {
    "kind": "section",
    "nodeId": "sec-1",
    "rule": "applies within this agreement unless overridden"
  },
  "exceptions": ["except as stated in Schedule B"],
  "crossReferences": ["Schedule B, Section 2"],
  "provenance": {
    "page": 2,
    "bbox": [72, 330, 514, 383],
    "sourceText": "\"Authorized User\" means …"
  }
}

The rule field need not pretend that a parser has solved legal interpretation. Its job is to preserve the language and structural context that a reviewer needs to assess applicability.

4. Extract references as typed, version-aware records

References take many forms: section cross-references, statutes, regulations, standards, publications, URLs, contract schedules, and internal document IDs. Capture the original citation exactly first. Normalize it second.

For every candidate, record:

• displayed citation text;
• reference type, such as internal_clause, standard, regulation, or statute;
• cited unit, such as section, chapter, title, or annex;
• edition, publication date, amendment, or revision when stated;
• whether the reference is dated or undated;
• local context and source span;
• resolution status and any ambiguity.

Government citation metadata distinguishes references to other documents and supports categories such as U.S. Code, CFR, and public or private law citations. That is a useful model: preserve the citation category and cited identifier rather than storing every reference as an untyped string. United States Code: GovInfo Help

Separate normative from informative references

In technical standards, placement and wording matter. ISO house style identifies Clause 2 as “Normative references” and Clause 3 as “Terms and definitions,” while distinguishing those from bibliographic material. ISO House Style

Use section context as a strong signal, then inspect modal language and local qualifiers. A document listed in a normative references clause is a strong candidate for normative; a source appearing in a bibliography or explanatory note is usually a candidate for informative. Still, store a confidence level and the evidence used for classification rather than flattening every reference into a hard assertion.

Edition handling is equally important. For dated references, only the cited edition applies; for undated references, the current edition and amendments may apply. ISO/IEC/NISO STS Coding Guidelines Never silently replace a cited edition with a newer one during resolution.

A small PagePith demonstration

The supplied PagePith proof shows a fetch of the PagePith homepage titled “PagePith — turn any URL into clean, usable data,” with a captured Markdown excerpt. That excerpt describes a web, PDF, and social-video content API, and it shows an API playground example for POST /v1/api/scrape that returns Markdown-oriented response fields.

For an extraction workflow, the relevant takeaway is narrow: Markdown can be a useful review format after content acquisition because humans can inspect headings, paragraphs, and nearby context without reading raw PDF objects. The supplied proof does not demonstrate extracting a particular legal definition, resolving a standards citation, or validating a PDF layout. Those semantic and provenance checks still belong in your pipeline.

If you want to evaluate the acquisition layer against your own documents and review the returned content, try PagePith.

5. Validate relationships against source evidence

Extraction quality is not the number of matches. It is the percentage of records a reviewer can verify quickly and confidently.

Apply validation in layers:

1. Span validation: confirm that the stored text, page, and bounding box point to the candidate phrase.
2. Structural validation: ensure a section reference resolves to a real node and is not a header/footer artifact.
3. Scope validation: flag definitions with words such as “only,” “except,” “unless,” or “for purposes of.”
4. Resolution validation: keep the cited string, parsed identifier, and resolved source/version separate.
5. Human review: queue low-confidence, conflicting, and cross-page candidates.

A review queue is particularly valuable for column breaks, definition tables, nested exceptions, and references whose edition is missing. For each review decision, retain the reviewer action and rationale. That history makes the system easier to debug when a parser changes or a document is reissued.

A durable implementation pattern

A robust pipeline usually looks like this:

Acquire original → classify PDF/text/OCR → extract tokens with locations
→ reconstruct structure → detect definition/reference candidates
→ normalize entities → assign scope and reference type
→ resolve cautiously → validate spans → review exceptions → publish records

Keep the original document immutable. Store derived text and normalized records as separate artifacts linked to the extraction run that produced them. When rules improve, rerun the pipeline and compare records by source span and normalized identity rather than overwriting history.

The result is more than a glossary or a citation list. It is a navigable evidence layer: terms link to scoped meanings, citations link to typed targets, and every relationship can be traced back to the passage that justified it.

Ready to test a content-acquisition workflow alongside your own extraction and review logic? Sign up for PagePith.