Locate PDF answers by yes/no halving

01 · Role in the system

What Jev does here

No OCR and no text layer: 200 pages become 100 side-by-side pair images screened in four parallel requests, pages that say yes are re-checked alone because the model sometimes mixes left and right, then four overlapping crops halve repeatedly until a few lines remain. Highlighting is pure probing - a red line slides until 'is the line above the answer without touching it' flips, edges blank out until 'is any letter visible' flips - and every probe is asked twice, once inverted, with answers averaged. On the author's generated 200-page demo the right page is found every time, the highlight lands within about 7-14 px, and a full run takes about 10 seconds and $0.013, because each image costs roughly 2,000 tokens while a question costs about 25 - few images, many questions each.

02 · Control boundary

Where Jev sits

Jev as the only sensing primitive in a geometric search: code owns the halving tree, crop sizes and edge movement, and converts yes/no probabilities into coordinates - search by bisection, localize by threshold flips, averaging inverted probes for stability.

Code owns the loop, permissions, thresholds, validation, and side effects. Jev owns only the bounded judgments described above.

03 · Known limits

What this evidence does not prove

• Numbers are author-reported on a self-generated demo PDF; no benchmark across real scanned documents.
• A quick POC (0 stars) with an OpenAIDecisions alternative decider beside the Jev path.
• Edge probing assumes axis-aligned answers; rotated or multi-column layouts are untested.

04 · Attribution

Public sources

This is a Community record: the project was published by a third-party community author.

• Empatixx ↗Community · github · public · checked 2026-10-17