VectifyAI / jev-doc-search

**Find the page that answers a question in a 300-page report with Jev's `Choice`. No vector DB or embeddings!**
Jev answers multiple-choice questions: give it the options, and it returns a probability for each. "Which page answers this question?" is one of them, and it works well, until the document outgrows what Jev can read at once. PageIndex removes that limit by turning the document into a hierarchical tree representation. Jev picks a node, then one of its children, and so on down the tree, choosing among a handful of options each time, however long the document.
## Page search with Jev's `Choice`
Page search can be framed as a multiple-choice question. The question is "which page answers this?", and the options are the pages themselves: each page is one option, described by its own text. Jev reads every option and returns a probability for each page; the most likely page is the answer. We call this flat page search: one `Choice`, one option per page.
To try it on a short PDF of your own, such as an employee handbook, run page_search.py (see Setup for installing and API keys):
 [code] 
It prints the most likely page and its text. The core of it is a single call:
 [code] 
In the code:
- **`state`** is what Jev reads before deciding. Here it is just the question.
- **`Choice`** is the decision. Its options go in `criteria`: one key per page (`p1`, `p2`, …), each described by that page's text.
- **The answer** names the most likely page in `choice`, with every page's probability in `probabilities`, summing to 1.
### Why flat page search breaks on long documents
Flat page search hits two limits, one after the other:
1. **Too many tokens.** Every page's text goes into the request as an option, and `state` plus the `Choice` must fit in 32k tokens. That runs out after a few dozen pages. NVIDIA's 10-K for fiscal 2026 has only 93 pages, but its text is about 76k tokens, more than twice what fits.
2. **Too many options.** A `Choice` takes at most 255 options, so one option per page stops at 255 pages. Some annual reports are longer than that: Citigroup's 10-K for 2025 has 318 pages.
PageIndex solves both at once. It turns the flat choice over pages into a tree: the document splits into sections, each with a title and a short summary, and each section into its pages. Jev then makes one small choice per level instead of one huge one, so every `Choice` has only a handful of options and fewer tokens.
## Tree search with PageIndex
### 1. Build the tree with PageIndex
PageIndex builds the tree from the document's own structure. The root is the whole document, its children are sections, and each section has a title, a summary, and a page range, down to the pages.
Submit the PDF and read its tree:
 [code] 
`tree` is a list of nodes, each with its `title`, its page range (`start_index` to `end_index`), a `summary` of those pages, and its children in `nodes`. For the NVIDIA 10-K it looks like this (abridged):
 [code] 
### 2. Search the tree with Jev
Jev starts a