Procurement triage on a local 30B model: 2,000 listings a day, 50 worth reading

Five portals, five logins, roughly 2,000 new listing rows a day. A bid writer was spending the first hours of every morning deciding what not to read. Missed deadlines and missed set-asides were the quiet cost.

A 16-stage pipeline, each stage an independent module with state passed through SQL Server rather than memory. Playwright handles the logins and downloads; a 93-keyword filter removes about 92% of rows before any model is involved; the model is asked four narrow questions per bid — eligibility, commercial terms, technical requirements and submission mechanics — against anchored passages, never the whole document.

The daily output is a register spreadsheet, two PDFs and an email to four people. A bid that is waiting on a human login is reported as such, not as a failure.

We ran eight cached notices through both nemotron-3-nano (30B) and nemotron-3-super (120B) on byte-identical input. Verdicts were 7/7 identical. The 30B model ran in 59 seconds against 651 for the 120B, found 11 fields the larger model left empty, and never timed out. The 120B also returned three fabricated exclusions — the error nobody notices, because a wrong exclusion produces no row at all.

Exclusion flags are honoured only if the triggering language actually appears in the document. Truncated model output is salvaged field by field rather than discarded. Nothing leaves the host: the models run under Ollama on a desktop GB10 system, and the project deliberately does not defeat bot protection — where a portal blocks automation, a person logs in and only the session cookie is imported.