doc-router

How we reviewed this: we built it in Docker, ran the workspace tests, and then classified its own fixtures and adversarial corpus with both the built-in heuristic and the Jev judge, using a real key.

What it does

doc-router, by Misbah Syed, looks at a PDF page by page and decides which pages have a usable text layer and which genuinely need OCR. Text pages are extracted locally, in-process; only the rest go to your OCR provider; the halves merge back in page order.

The judge is one trait with two implementations: a zero-dependency local heuristic (the default) and Jev, which is asked one Noul per page:

That page needs to be re-read with OCR: the text it carries is missing, or it is present but does not faithfully represent what is printed on the page.

The criteria spell out the cases that matter — mojibake from a broken encoding, a bad pre-existing OCR layer, a page whose only text is a watermark.

275 tests pass, and the core library makes no network calls at all.

Where the judge earns its place

On an ordinary mixed fixture, both judges agreed: pages 1 and 3 are scans.

The interesting run is the project’s adversarial corpus — synthetic pages built to defeat structural heuristics. A pre-OCR’d scan carries a full hidden text layer, so nothing structural objects to it, but the transcription is mangled (“G0OD5 RECEIVED LOG”, “deliverthe ’goods describcd”). A report with a broken ToUnicode map extracts as plausible-looking nonsense.

The local heuristic flagged none of those pages — on both documents it reported nothing needing OCR. The Jev judge flagged most of them: four of six on the pre-OCR’d scan, five of five on the broken-encoding report.

That is eleven synthetic pages, built by the author to make this exact point, and it is not a benchmark. But it is a clean illustration of what a meaning-level judge adds to a structural one: the heuristic can only see that text exists, not that the text is wrong.

On a twelve-page mixed document, the two judges disagreed in both directions against the labels — the Jev judge flagged more pages than the truth file lists. Both judges are advisory; the decision you care about is cost versus a missed page, and the README says so.

What it sends

Per chunk of pages: the page’s evidence — extracted text, character statistics, structural signals — as the state, with one question per page. That means page text leaves your machine for the pages being judged, which for a document you were about to send to a hosted OCR service anyway is a small marginal step, but worth stating.

The README’s own measured comparison of routed versus OCR-everything is the author’s, measured against a paid provider through a gateway; we don’t republish those figures.

Verdict

Small, careful, and aimed at a real bill. The trait boundary means you can start with the free heuristic and switch judges when you have documents that fool it — and if your corpus is full of pre-OCR’d scans, the second kind of judge is the one that sees them.

Two commits old, MIT licensed, with a written spec and a guide. Read the data-flow section before pointing it at client documents.

For the other document tool, see tax-doc-classifier.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 20, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.