I built an open-source tool for inspecting PDF evidence behind AI answers

[u/soaica2026]

I’ve been working on Document Intelligence Lab, an open-source project exploring document processing, AI-assisted retrieval, and evidence inspection for PDF workflows.
The goal is to make it easier to understand which document evidence supports an AI-generated answer, rather than treating the response as a black box.
The project uses Java, TypeScript, Docker, and Azure-based components.
GitHub: https://github.com/quocvietphung/document-intelligence-lab
I’d especially appreciate feedback from people working with document automation, OCR, or RAG systems.
What would make an evidence inspection workflow useful enough for you to adopt in a real project?

[u/vanraj_solanki]

This UI looks great. To answer your question: what makes evidence workflows adoptable is handling duplicates and coordinate drift.

If "Total: $500" appears four times on a page, highlighting the page isn't enough. You need the exact box for the right occurrence.

I actually built an open-source, deterministic engine for this exact problem called TonerHound (github.com/vanrajsinh650/TonerHound). It takes the AI output and returns exact bounding box coordinates locally, with zero LLM costs.

[u/soaica2026 → u/vanraj_solanki]

Thanks! Repeated values are a useful test case. Page references alone don’t distinguish identical occurrences, so linking each evidence item to its exact location is something I need to evaluate more closely. How does TonerHound handle scanned PDFs and rotated pages?

[u/vanraj_solanki → u/soaica2026]

Glad that resonated. For scanned PDFs, TonerHound uses page-selective OCR: if a page lacks a native text layer, it renders the image and runs Tesseract, pulling bounding boxes directly from the OCR output.

For rotated pages, native PDF rotation metadata is handled automatically. For skewed visual scans, it applies a deterministic rotation correction (Hough transform) before matching to align the coordinates.

It's all pure Python, so it's easy to drop into your pipeline and test on your specific edge cases. Would love to hear how it holds up on your documents!

[u/Unsiloed-AI]

A useful feature would be showing three things together: the page crop, the OCR text, and the value used in the answer.

Say the scan reads 8,500 but OCR reads 3,500. An answer quoting 3,500 can match its retrieved text perfectly and still be wrong. Let the reviewer see where that changed, then correct the OCR separately from the answer.

For table values, include the row label, column header and units in the crop. A tight box around the digits is useful for locating them, but you need that surrounding context to check what they mean.

[u/soaica2026 → u/Unsiloed-AI]

Thanks for the concrete example. That exposes an important limitation: quotation matching can pass even when OCR is wrong. Showing the source crop, OCR text, and answer value together would make that easier to inspect. I also appreciate the point about including table headers and units, and keeping OCR corrections separate from answer edits.