This week built the argument in pieces. Tuesday: a free 3B model reads 40 pages in one pass on your own hardware. Wednesday: the AI Act’s transparency rules land regardless of where your weights run, but local inference simplifies the data-governance stack. Thursday: Hugging Face demonstrated, under fire, that a capable model on your own infrastructure is an operational requirement. Friday: the memory market explained why doing the job in 3 billion parameters is engineering, not ideology.
This is the piece those four were pointing at: the reference architecture. Documents in, typed database rows out, nothing leaving your building. It’s the pipeline running in production here, described at the level that stays true across model versions — every version-pinned command lives in the companion repo, because model tooling this young rots in weeks and a book-length article shouldn’t rot with it.
Documents in. Typed rows out.
Nothing leaves the building.
The reference architecture this week was pointing at: a hash, a Postgres queue, two model passes, a review loop, provenance columns — boring architecture around rapidly-improving models. Commands live in the companion repo; the design lives here.
Five stages, one spine
Idempotent by content hash: reprocessing is always safe, “did we do this file?” is a primary-key lookup. Two model passes on purpose — transcription errors and extraction errors have different fixes.
The four principles everything hangs on
Exceptions are the product
Confidence routing
Low-confidence fields, schema failures, unparseable pages → human_review jobs in the same queue. Corrections stored as data — your ground-truth set for the next model swap builds itself.
Field observations
Exception rate is dominated by input quality, not model quality — a scanner upgrade often beats a model upgrade. And a 93% benchmark means the real design problem is the other 7%.
- Low volume: under ~10–20K pages/month, one week of this engineering costs more than a year of API invoices.
- Prebuilt schemas fit: if your documents are exactly the invoice/receipt/ID categories and DSGVO permits, the cloud prebuilt tier is the honest recommendation.
- Degraded inputs: phone photos and crumpled scans invert the benchmarks (Real5-OmniDocBench). Test on YOUR documents first.
- No owner: a local pipeline is infrastructure. If nobody patches it and watches the dead-letter queue, buy the cloud’s real product — their ops team.
DSGVO: what local removes
The Auftragsverarbeitung surface for processing itself — no vendor DPA, no transfer analysis, no sub-processor audits for the core path.
DSGVO: what remains
GDPR itself. Purpose limitation, retention, deletion, access controls — local processing is still processing. Simplifies compliance; never waives it.
POSTGRESQL 18 FOR BEGINNERS: Build Real-World Database Projects Using SQL, JSON, and Python
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Design principles before boxes and arrows
Four decisions shape everything downstream, and they’re worth stating as principles because you’ll face each one again whenever a component changes.
The model is an appliance, not a framework. The OCR model does one thing: pixels in, markdown out. It doesn’t orchestrate, doesn’t retry, doesn’t touch the database. The moment model code grows opinions about your pipeline, you’ve coupled your architecture to the most rapidly-deprecating component in it.
Python stays at the ML boundary. Each ML capability is a narrow, single-file CLI — transcribe-grade simplicity: read input path, write JSON to stdout, exit nonzero on failure. The orchestrating service invokes them as subprocesses. This is the same discipline that keeps larger systems maintainable: Python where the ML ecosystem forces it, nothing more.
The queue is the architecture. Everything between ingestion and storage is a job in PostgreSQL, claimed with SELECT … FOR UPDATE SKIP LOCKED. No Redis, no RabbitMQ, no separate broker to operate, back up, and secure. If you already run Postgres — and this pipeline does, because the output is Postgres rows — a ~150-line queue on SKIP LOCKED gives you concurrent workers, crash-safe claims, and transactional job completion in the same database as your data. The operational surface you don’t add is the best kind.
Idempotency by content hash. Every document is identified by its content hash on ingest. Every derived artifact — page images, markdown, extracted rows — keys back to it. Reprocessing is always safe, retries are always safe, and “did we already do this file?” is a primary-key lookup.
HP Digital Sender Flow 8500 fn1 OCR Document Capture Workstation (Renewed)
- Refurbished and Certified: Tested, cleaned, and certified to look and work like new
- High-Speed Scanning: Up to 60 pages per minute, 120 images per minute
- High Daily Capacity: Scan up to 5,000 pages per day
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Stage by stage
1 — Ingest and normalize. Watch folder, upload endpoint, or mail-in: whatever the source, the first stop writes the original bytes to storage, computes the hash, records a documents row, and enqueues a render job. PDFs become per-page PNGs at ~300 dpi — the resolution floor below which OCR quality quietly degrades. Nothing intelligent happens here on purpose; ingestion should be too boring to fail.
2 — OCR as a narrow CLI. One subprocess call per document (or per chunk — see below): page images in, markdown out, plus a sidecar JSON of per-page status. Model choice is a routing decision, not a religion. On current published numbers: the one-shot multi-page architecture (Unlimited-OCR) is the pick when cross-page structure matters — contracts, reports, books; the page-by-page 0.9B specialists (PaddleOCR-VL class) score higher on single-page accuracy and dramatically higher on physically degraded inputs. Because the CLI contract is identical either way, swapping or A/B-ing models is a config change. Design for that swap: this layer will be replaced within a year, and the pipeline shouldn’t notice.
3 — The queue in the middle. A single jobs table: id, type, payload, status, attempts, locked_at, last_error. Workers claim with SKIP LOCKED, process, and complete inside a transaction. Three details earn their keep in production: a max-attempts threshold that routes repeat failures to a dead-letter status instead of infinite retry; a lock timeout sweep that reclaims jobs from crashed workers; and per-type concurrency caps, because one 40-page OCR job and forty single-page jobs should not compete blindly for the same GPU seconds. That’s the entire queue. Resist the urge to make it interesting.
4 — Structured extraction. OCR output is markdown; businesses run on typed fields. The second model pass — the local daily-driver LLM, Qwen3-32B-class — turns markdown into rows against an explicit schema: prompt states the fields, types, and a required confidence and evidence (source span) per field; output is validated JSON, rejected and retried once on schema failure. Two passes, deliberately separate: transcription errors and extraction errors have different fixes, and collapsing them into one magical step makes both undebuggable. Keep extraction prompts in version control next to the schema they serve — they are code.
5 — Storage with provenance. Extracted rows land with provenance columns: source document hash, page span, model identifiers for both passes, timestamps, confidence. When a number in a report is questioned eight months later, the answer is a join away — which document, which page, which model version, how confident. In regulated contexts this isn’t a nice-to-have; it’s the difference between an audit and an archaeology project.
As an affiliate, we earn on qualifying purchases.
Exceptions are the product
Here is where this article shakes hands with Friday’s Post-Labor piece. A 93% benchmark score means the pipeline’s real design problem is the other 7%.
Route on confidence: extraction fields below threshold, schema-validation failures, and OCR pages flagged unparseable go to a review queue — the same jobs table, type human_review, surfaced in whatever review UI fits. The reviewer sees the page image and the extracted candidate side by side, corrects, and their correction is stored as data — building, over time, exactly the ground-truth set you’ll want for evaluating the next model swap.
Two honest observations from running this. First, exception rate is dominated by input quality, not model quality — a scanner upgrade at the source often beats a model upgrade in the pipeline. Second, the human role this creates is precisely the one Friday’s article described: reviewing the machine’s uncertain cases. Fewer people than the keying era, different skill, and the pipeline should be designed to make that role effective rather than residual.
![Express Schedule Free Employee Scheduling Software [PC/Mac Download]](https://m.media-amazon.com/images/I/41yvuCFIVfS._SL500_.jpg)
Express Schedule Free Employee Scheduling Software [PC/Mac Download]
- User-friendly drag & drop planning: Simple shift scheduling interface
- Manage time-off and holidays: Add sick leave, breaks, holidays
- Email schedules to staff: Send schedules directly via email
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
When to chunk despite “unlimited”
Tuesday’s caveat, operationalized: a 32K context is a hard budget covering the visual tokens and the transcription output. Dense pages run ~600–1,000 output tokens each; the practical one-shot ceiling on current tooling sits in the dozens of pages, not hundreds. The pipeline therefore chunks anything book-length at structural boundaries — chapters, sections, the places where cross-references naturally thin out — and treats each chunk as a one-shot job. You keep the cross-page benefits where they matter (tables and references rarely span chapter breaks) and stay inside the context budget. “Unlimited” is a brand name; your chunking.ts knows the actual number.
When this whole architecture is the wrong call
House rule, applied to our own architecture. Do not build this if:
Your volume is low. Below roughly 10–20K pages a month, a commercial OCR API costs less per year than one week of the engineering above. The pipeline earns its keep on volume, data sensitivity, or both — if you have neither, pay the invoice and move on.
You need typed key-value extraction off the shelf. Azure’s and Google’s prebuilt invoice/receipt/ID models ship the schema, the training, and the accountability. Stage 4 above rebuilds a general version of that; if your documents are exactly the prebuilt categories and DSGVO permits the processing, the cloud tier is the honest recommendation.
Your inputs are photographs of the physical world. The published degraded-document numbers (Real5-OmniDocBench) are unambiguous: the model families this pipeline favors drop hard on warped, skewed, phone-photographed inputs. Crumpled-receipt workloads need either the robustness-focused specialists or a different plan. Test on your documents before committing — benchmark deltas of ten points routinely invert on domain data.
Nobody owns it. A local pipeline is infrastructure. If there is no person on the team who patches it, monitors the dead-letter queue, and re-evaluates models quarterly, the cloud API’s real product — someone else’s ops team — is the right purchase.
The DSGVO section, stated carefully
What this architecture removes: the Auftragsverarbeitung surface for the processing itself. No OCR vendor DPA, no third-country transfer analysis for document contents, no sub-processor list to audit for the pipeline’s core path. For legal, medical, HR, and due-diligence documents, that deletes a whole category of compliance work and — after Wednesday’s article — simplifies the data-governance documentation the AI Act era expects.
What it does not remove: GDPR itself. Local processing is still processing. Purpose limitation, retention schedules, deletion on request, access controls, and records of processing all apply to the Postgres tables exactly as they would to a SaaS. The provenance columns from Stage 5 help here too — deletion by document hash cascades cleanly. Local-first simplifies compliance; it never waives it. This site will keep saying both halves.
Bottom line
None of the components above is exotic — a hash, a queue, two model passes, a review loop, provenance columns. The design’s entire value is in what it refuses: no broker, no framework coupling, no magical single pass, no pretending the 7% away. Boring architecture around rapidly-improving models is the trade that ages well: this pipeline has already survived one OCR-model generation and is built to survive the next one as a config change.
The week’s argument, compressed: the models became good enough, the law rewards keeping data home, the incidents punish depending on someone else’s policy, and the memory market punishes depending on someone else’s capacity. The pipeline is just those four facts, arranged into tables and arrows.
Version-pinned setup, schema DDL, and the queue implementation live in the companion repo.
Sources
- ThorstenMeyerAI.com, this week’s series: “Baidu’s Unlimited-OCR Reads a 40-Page PDF in One Pass” (July 21, 2026 — benchmark figures and model comparison as sourced there); “August 2 Is Still Real” (July 22, 2026); “When the Cloud Says No” (July 23, 2026); “Who Processed Documents for a Living” (July 24, 2026)
- Real5-OmniDocBench, arXiv:2603.04205 (2026) — degraded-document robustness deltas cited in the wrong-call section
- PaddleOCR-VL 1.5 technical report, arXiv:2601.21957 (2026) — single-page specialist accuracy basis
- PostgreSQL documentation —
SELECT … FOR UPDATE SKIP LOCKEDsemantics - Regulation (EU) 2016/679 (GDPR) — processing obligations referenced in the DSGVO section
Architecture described as running in production on the author’s fleet; throughput and exception-rate observations are field experience, not benchmarks. Commands, versions, and DDL: companion repo.
