The contents tree

A long document already carries its author's map: the table of contents. Vectorless uses that map as the index, after checking it against the body.

From contents page to tree

For a PDF in toc mode, the engine:

1. reads the layout of every page with pdfgrab;
2. finds the contents page and its entries, with Jev confirming each one;
3. places each entry on the page where its heading actually appears;
4. splits any section longer than 20 pages at its own headings.

The result has this shape (an illustration; the titles and page numbers are examples, not output from a real run):

3M 2018 Form 10-K
├─ Item 1. Business                         pp. 4–9
├─ Item 1A. Risk Factors                    pp. 10–12
├─ Item 7. Management's Discussion          pp. 20–45
└─ Item 8. Financial Statements             pp. 46–120
   ├─ Consolidated Statement of Income      p. 48
   ├─ Note 1. Significant Accounting...     pp. 54–62
   └─ ...

Every leaf has a title from the document and a page range in the PDF. The text of every physical page is stored separately, so navigation reads real pages, not sections stitched from them.

Why this tree

• It is the author's structure. The titles and their order come from the document, not from a model's summary of it.
• It locates. On FinanceBench, splitting long sections shrank the median leaf that holds a gold evidence page from 37 pages to 6, while every gold page stayed inside a leaf (47/47, 2026-09-19).
• It is cheap to build. On 21 FinanceBench filings, the contents stage cost $0.0003–0.0015 per filing on Jev against $0.017–0.095 on a generative model (2026-09-18). See Benchmarks.

Documents without a contents page, and formats without pages (Markdown, HTML, DOCX, text), get a tree from their headings instead.