kind that describes what structural role it plays in the document — a form, an endorsement, a section, a schedule, and so on. This design keeps form identification grounded in the actual document layout rather than a secondary classification step.
DocumentSourceNodeKind
Every node in the source tree is typed by itsDocumentSourceNodeKind:
form and endorsement are the primary anchor points for form inventory. Their id, title, and child nodes are derived directly from headings and form numbers found in the source text.
Form Inventory as a Compatibility Projection
Three surfaces in the extraction result expose aformInventory field:
document.formInventorydocumentMetadata.formInventoryreviewReport.formInventory
form and endorsement nodes in the source tree. You do not need to populate them manually — they are materialized automatically during phase 7 of the pipeline.
Each entry in the inventory conforms to the FormReference schema:
string
required
The form number as it appears in the source document (e.g.
"CG 00 01", "ISO-GL-2019").string
The edition date printed on the form, if present.
string
The form’s title derived from source headings. Titles are kept terse — they reflect the source text and are not rephrased.
"coverage" | "endorsement" | "declarations" | "application" | "notice" | "other"
The structural role of the form within the policy package.
Coverage Lines vs. Legacy Flat Rows
For v3 source-backed extraction, prefer reading coverage data fromoperationalProfile.coverages rather than from the legacy flat compatibility rows in document.coverages. The operational coverage lines carry structured limits and direct source references:
OperationalCoverageTerm[]
Structured limit terms for this coverage line. Each term carries a
kind (e.g. "each_claim_limit", "aggregate_limit", "retention") and a value string.string[]
References to
DocumentSourceNode.id values in the source tree. Use these to navigate to the relevant form or section node.string[]
References to
SourceSpan.id values. Combine these with your parser’s bounding boxes to render PDF highlights in your UI.Practical Guidance
Index the Source Tree
Build an ID-keyed index of
result.sourceTree to support fast document navigation and targeted retrieval without re-traversing the full tree.Use Span IDs for Highlights
Pair
sourceSpanIds with the bounding boxes your parser (Docling, PDF.js, etc.) recorded to render precise PDF highlights in a review UI.Trust Source Heading Titles
Let the pipeline derive titles from source headings. Don’t override or rephrase them — terse, verbatim titles keep the source tree predictable across documents.
Avoid Duplicate Grouping
Don’t maintain a second form-grouping system in your application. The source tree is already the canonical structure — additional grouping logic diverges from it and creates maintenance burden.
Querying the Source Tree
The following example collects allendorsement nodes from the source tree and logs their form numbers: