Notarial Practice Digitisation — Consultant & Tech Lead

Challenge

A notarial practice had commissioned a bespoke system to move data from clients' online intake checklists into their case-management software largely automatically — opening files, recording parties, filing identity documents, preparing deadlines. It had been built by a single developer and had reached early production use.

Two things were needed. Identity documents — passports and ID cards — had to be read reliably enough to be trusted in a legal case file. And the practice wanted an independent view on whether a system now handling confidential client data was safe, correct and maintainable enough to keep running and eventually hand over.

I joined as consultant and technical lead. The developer owns day-to-day implementation; I set direction, review the work, and take on the pieces that need a second perspective.

Implementation

Identity-document reading. I introduced Regula Document Reader as the OCR foundation and built the spike that became the production integration path. Inputs are normalised from HEIC, JPEG and PDF sources, and an image-quality assessment step catches unusable scans before they reach extraction — a blurred photo should fail early and visibly, not silently produce a plausible-looking wrong name.

Designing for uncertainty. The machine-readable zone on an identity document only carries check digits for some fields, so a document reader can confirm certain values cryptographically and merely transcribe others. I built the extraction logic around that distinction: unverifiable fields are marked as unverified rather than being presented as confirmed, comparisons that could not actually be performed are flagged conservatively, and results from multiple sources merge per source instead of overwriting each other. For documents that end up in a legal file, reporting uncertainty is more useful than guessing well.

The review. A structured assessment across four dimensions — data correctness, security and access, reliability, and speed and maintainability — delivered as a written report. Every source file, message and transcript was tracked in a per-item checklist across the main repository and all submodules, so coverage was demonstrable rather than asserted. Internal working evidence was kept separate from the client-facing document; anything that turned out on closer inspection to be a non-issue or already resolved stayed out of the report entirely.

Technical Highlights

Writing for two audiences at once. The report had to serve practice leadership — expert in notarial work, not in software — and the developer implementing the fixes. Rather than simplifying and losing precision, every point carries two layers: a plain-language explanation with a concrete example of what it means for a client file, and a separately labelled technical section naming the mechanism and a proposed approach. One document, two entry points, no translation step in between.

Thinking in consequences, not severities. Findings were framed in terms of what they mean for a case file, for liability, and for time spent in the office — the terms in which the practice actually makes decisions — rather than as an abstract severity ranking.

Result

The practice received a decision-ready assessment: what already worked solidly, what warranted attention, and a phased plan they could act on without a software background. The OCR integration went in on the principle that a system handling identity documents should surface what it cannot confirm — the right posture under both professional confidentiality obligations and GDPR rules on special-category data.

Out of respect for the practice's confidentiality, no specific findings, systems or identifying details are described here.