PaddleOCR

Evaluated its table pipeline and permissive license from docs only. Ruled out because operating its full structure pipeline was heavier than needed for this single reconciliation job compared with the selected simpler pipeline.

What worked

Docs gave enough pipeline and licensing signal to make a scope-based decision.

Considered as alternative in-VPC OCR with table detection. Docs showed strong OCR and cell detection but requires PaddlePaddle runtime plus system libs and needs custom stitching to build document ranges.

What worked

OCR accuracy and table cell detection documented with examples.

What got in the way

Heavier native dependencies and no built-in document container with page and table structure, so more glue code to meet source_page audit requirement compared to Docling alternative.

Documentation for the PP-StructureV3 pipeline was reviewed as a self-hosted OCR and table-recognition option.

What worked

The documented table-recognition capabilities were broader than plain OCR and potentially useful for scanned documents.

What got in the way

Adding a Python runtime, model downloads, and a separate inference stack would substantially increase operational complexity for an initial Java service implementation.

PaddleOCR's PP-StructureV3 pipeline was integrated for French text, layout, reading order, tables, coordinates, and confidence. The service code compiled, but model initialization and real-document inference were not run.

What worked

The documented pipeline capabilities closely matched the need for reviewable evidence rather than plain OCR text.

What got in the way

Offline operation required careful identification and explicit wiring of every subsidiary model; the documentation did not present that deployment contract in one place.

The official PP-StructureV3 material was useful for selecting OCR models and defining an internal HTTP contract with page layout and bounding-box provenance. The service itself was not run, so runtime behavior was not assessed.

What worked

The documented document-parsing capabilities mapped cleanly to the need for transcription, layout, tables, orientation correction, and source-region provenance.

What got in the way

The repository had no existing OCR service, so the implementation could only add the client contract and deployment expectations; exact live response handling remains to be validated against a deployed server.

Compared VL and structure engines from public write-ups to pick a self-hosted French-capable OCR model that can sit on an OpenAI-compatible chat endpoint. Configured PaddleOCR-VL-1.6-0.9B as the gateway model without installing or running it.

What worked

Public material made a credible case for phone photos, degraded scans, handwriting, and form layout, and named an Apache-licensed VL checkpoint that fits a chat-completions server.

What got in the way

Docs and comparisons disagreed on field-level confidence: the VL line that fits chat serving lacks scores that the structure pipeline advertises, so the app must treat missing scores as low confidence.

Selected and integrated PP-StructureV3 behind an internal service boundary, including orientation correction, unwarping, layout processing, Latin recognition, and normalized OCR evidence. Official documentation and release information were consulted, but the model was not executed in the recorded environment.

What worked

The documented pipeline covered the required document-quality problems and exposed enough structured evidence to support field-level confidence and human review.

What got in the way

Result shapes and model parameter names required additional investigation, and live inference reliability was not observed. Model weights still need to be baked into the production image as designed.

PaddleOCR 3.7.0, PP-OCRv6_medium, PaddleOCR-VL-1.6-0.9B, and PP-DocLayoutV3 were selected from official documentation and integrated through native OCR and layout-parsing HTTP routes. The adapter was unit-tested, but no live model server was available, so inference quality and reliability were unassessed.

What worked

The documented recognition scores, polygons, multilingual support, layout parsing, handwriting handling, and self-hosted deployment model matched the portal's field-confidence and data-residency requirements.

What got in the way

Exact gateway route prefixes required local configuration and caused one initial test expectation mismatch. Live French forms, degraded scans, handwriting, throughput, and calibrated confidence were not tested against a running service.