The architecture behind hours-to-seconds document processing at a law firm: classification, confidence thresholds, and filing conventions as code — plus the two document types that humble every first version. Public excerpt; the full teardown lives in the Builder library.
The target our legal document builds aim at is hours-to-seconds per document: what a paralegal used to read, rename, file, and log by hand becomes automatic classification and filing at arrival. The pipeline is simple to describe and the value lives in three unglamorous details — the text layer, the threshold, and the conventions.
Stage 1 — Unified arrival. Email attachments, uploads, and scans converge on one processing queue. The detail that matters immediately: verify every document has a usable text layer at arrival. A scanned PDF without OCR is an image wearing a PDF costume, and everything downstream will confidently misjudge it. OCR-on-ingest is stage 1's real job.
Stage 2 — Classification and extraction. Document type, parties, matter references, dates — read from the document and matched against the firm's live matter list. Model choice matters less than people expect; the matching layer against your matters and your naming conventions is where accuracy is won.
Stage 3 — The threshold. Every classification carries a confidence score, and the pipeline has exactly two exits: file automatically, or route to a human with the suggested filing pre-attached. Where you set the threshold is a business decision dressed as an engineering one — too strict and you've automated nothing, too loose and one misfiled privileged document costs you the firm's trust in the entire system. Start strict. Loosen with evidence.
Stage 4 — Filing as code. Naming conventions and folder structures live in configuration, applied identically every time, into the firm's existing DMS through its API. Access scoping by matter, encryption, and an audit log of every automated action — the confidentiality envelope is the same one every legal build gets.
The email was the document. A one-line email with three attachments arrived, and the pipeline dutifully classified the attachments — while the email body ("Drafts for the Chen matter — the second one supersedes what we sent Friday") held the only context that made them fileable. Fix: the email is a document too. Body text rides along as classification context for its attachments, and threading links related arrivals.
Perfect-looking scans with garbage text layers. Some inbound PDFs had text layers — produced by someone else's bad OCR, wrong enough to misclassify reliably while passing every "has text" check. The fix was a text-quality gate, not a text-existence gate: score the layer, re-OCR below the bar. Trust no one's OCR, including the sender's.
The full teardown — the confidence-threshold tuning sequence, the filing-convention configuration format, the email-context extraction pattern, and the backfile-processing playbook — lives in the Builder library.
Implementation detail, checklists, and the parts we'd rather not have public — for members.
Unlock with Builder