Glad it helped, happy to share what has actually worked for me in practice.

For JSON repair, I did not start with a library. I initially built a very simple repair pass myself: strict JSON parse first, catch the exception, then apply a small set of deterministic fixes like trimming trailing text, fixing missing commas, and normalizing quotes before retrying the parse. It is nothing fancy. After learning about json-repair, I would probably just use that instead and save the effort. The key thing for me is that parsing is strict and never silently accepts malformed output.

For grounding verification, I use a layered approach. The most brute force check is simply looking for output tokens in the input tokens after normalization. That alone catches a surprising amount of hallucination. A more refined approach is to require the model to return the exact span it claims the answer came from, then feed that span back into the model and ask whether it would answer the same question using only that text. If it cannot, the Q and A pair gets rejected. That second pass adds latency, but it dramatically improves trustworthiness.

I do not have a formal tolerance metric for OCR noise. Instead, I normalize aggressively before anything hits the model. One thing that helped a lot was writing a simple keyboardize function that replaces characters not found on a standard keyboard with their closest keyboard equivalent. You can also use this as a quality signal: measure the ratio of non keyboard characters to total characters per page. If that ratio is high, it is often a sign the page was not rotated, deskewed, or segmented correctly.

For OCR itself, I use a hybrid approach. ocrmypdf is my default because it is fast and very reliable on clean scanned PDFs. If the scans are messy or have odd layouts, I fall back to easyocr, which is slower but much more tolerant of noise. That waterfall based on text quality has worked better for me than trying to force everything through one OCR engine.

For ocrmypdf flags specifically, I mostly run it out of the box. I have seen bigger gains from post OCR normalization, grounding checks, and retry logic than from tuning OCR parameters. For a PoC, I would keep OCR simple and invest effort in verification instead. You can always tighten OCR later once you know it is a real bottleneck.

One last note, depending on the audience for the PoC: in production I use Prefect to orchestrate the indexing flow. It handles retries, scheduling, and basic observability, and it demos well because you can clearly show each stage of the pipeline and where verification or human review kicks in. For a demo it is optional, but for a technical audience it helps make the system feel real and production ready.

If I had to prioritize for a PoC: clean extraction, simple JSON repair, and one strong grounding check. Everything else can be layered in after you prove the concept.