Engineering

Designing OCR pipelines for government bulletins

OCR · R2 · Document intelligence · LegalTech

Problem

Department of Industry trademark bulletins arrive as dense PDFs — tabular layouts, mixed Nepali and English text, application numbers embedded in irregular columns. Staff were re-typing entries by hand during filing season. The goal was structured register updates without asking practitioners to trust unverified machine output.

Context

OCR demos suggest the problem ends at text extraction. Production bulletins shift layout between issues. Bilingual marks break naive tokenizers. A misread application number creates false confidence in a conflict check. Legal workflows demand audit trails: which bulletin, which page, which field, who confirmed.

Constraints

Layouts change without notice. Nepali and English share the same page. Firms will not accept silent merges into client matters. The pipeline must attach to NepalIPMS auth, matters, and search — not live as a side demo.

Architecture

Upload → R2 → layout OCR → classification → field mapping → human review → search & reminders. Interactive walkthrough: architecture gallery.

Implementation

PDFs land in R2 with job metadata. Azure OCR returns layout-aware text blocks. A Cloudflare Worker parses bulletin structure — issue boundaries, application rows, class columns — and maps to the register schema with per-field confidence scores. The review queue lives in the same API surface as matter management. Confirmed rows update FTS5 indexes and link to existing matters where application numbers match.

Result

Bulletin intake moved from hours of manual entry to a confirm-and-merge workflow. Errors surface at review instead of in client calls weeks later. Search and renewal reminders only consume verified fields.

What I Learned

Separate extraction from intelligence. Keep humans at the merge gate. Provenance is part of the product. OCR that cannot explain which page a field came from will not earn desk trust.

← All essays