Ask an LLM a question about a folder of PDFs and it answers. That demo takes an afternoon. Everyone has seen it, and somewhere along the way "chat with your documents" started getting sold as a product.
It isn't one. It's the loading screen.
I built ClaimLens to find the line where the demo ends and the product begins. It takes the paperwork from a car accident - police report, medical records, itemized bills, insurance declarations, damage photos - and turns it into a review-ready demand package. Ordinary documents. Ordinary retrieval gets you about a tenth of the way.
The line is always in the same place. The chatbot retrieves a passage and phrases it nicely. The product does the work a person would still have to do after reading the passage. Here is what lives on the far side of that line.
01 - Structured extraction It puts the answer in a typed schema, not a sentence
A retrieval answer is prose. Prose can't be checked, sorted, summed, or gated.
ClaimLens doesn't tell you, "the medical bills total around eighteen thousand." It extracts every charge into a typed field, tags each one to a single evidentiary pillar - liability, injury, causation, or damages - and adds them. The output is a case file, not a paragraph.
Once facts are typed, everything downstream is arithmetic instead of vibes. Totals foot. Checks run. Exports work.
02 - Timeline intelligence It builds a timeline and runs it against real rules
Retrieval has no sense of time or law.
ClaimLens assembles every dated event across every document into one chronology, then runs Florida's no-fault rules over it. If the first treatment date minus the crash date is more than 14 days, it flags that PIP medical benefits are at risk.
Noticing the thing nobody asked about is the job.
03 - Completeness checks It knows what's missing
The hardest question in any document set is about the document that isn't there.
ClaimLens runs a checklist engine over the real demand-package list and flags the absent radiology report, the missing lost-wage proof, or the EMC determination that was never made.
Retrieval can only speak to text that exists. It is structurally blind to a gap. Half the value in a claim file - or a loan file, or a tax return - is catching what's not in the folder.
04 - Multimodal evidence It reads the photos as evidence, not decoration
Vehicle damage photos are a data source, not an attachment. ClaimLens runs a vision model over them and folds what it finds into the same typed record as the text - so a photo can support a causation claim, and the fact it supports is traceable back to the specific image.
05 - Auditability Every fact clicks back to its source - or the build fails
Each extracted fact links to the exact source page or photo, stays editable, and keeps its confidence score.
This isn't a UI nicety. The QA gate fails the build if any extracted fact lacks a resolvable citation.
In high-stakes work, an answer you can't trace is worse than no answer, because someone will act on it. Auditable beats confident.
The distinction In one line
A RAG chatbot retrieves and rephrases. A vertical document-AI product adds five things a chatbot can't:
- Typed extraction instead of free-form prose
- A timeline checked against domain rules
- Missing-document detection
- Evidence read out of images
- Citations that resolve - or the build fails
The retrieval step is maybe 10% of it. The other 90% is where the domain lives.
The real moat The 90% is domain, and the domain is learnable
Look at what those five capabilities actually require. Not one of them is a model problem.
The 14-day flag exists because Florida statute puts a hard gate on no-fault medical benefits, and missing it can kill the claim. The four evidentiary pillars come from how an adjuster actually reads a demand package. The checklist exists because there is a real, knowable list of what belongs in one, and the EMC determination is on it.
None of that is in the model. All of it had to come from statute, from practitioners, and from the documents themselves, before a line of code was worth writing.
That's the actual work. The retrieval pipeline was the easy part.
If you're evaluating whether to build one of these, budget for the domain, not the embeddings.
Privacy architecture Why it runs where it runs
Read the input list again - police reports, medical records, itemized bills, injury photos. There isn't one item on it you'd casually POST to a third-party endpoint. Medical records alone put you inside HIPAA before you've written any code.
So ClaimLens runs on local models. Nothing leaves the machine.
System spine
FastAPI - PostgreSQL + pgvector - Docling - one LLM adapter with hosted, local, and offline-stub modes
That switch is the difference between a demo you can show and a system a hospital or a law firm can actually put private data into.
There's a public demo running on synthetic data - no real people, no real claims - if you'd rather look than read.
The chatbot is where you start because it's easy and it's a good loading screen. If that's also where you stop, you've shipped the loading screen.




Leave a Comment