DataForge: AI Mining Report Intelligence with Page Evidence

DataForge turns long, scanned mining reports in English, Hindi and Telugu into structured data, tracing every figure to its source page and flagging conflicting figures automatically.

Comment

Inspiration

Mining organisations like CMPDI and the Coal India subsidiaries run on reports: annual reports, production returns, exploration and compliance documents. The figures inside them (production, reserves, locations, dates) feed planning and official replies, yet finding one figure means reading by hand, often through scanned pages in English, Hindi or Telugu. When a revised report contradicts an earlier one, nothing alerts anyone.

We wanted to see that for ourselves, so we took a real published report, the Bharat Coking Coal Limited Annual Report 2024-25: 342 pages, 21 MB, about 750,000 characters. Our first version read only the first 8,000 characters of it:

$$\frac{8{,}000}{750{,}000} \approx 1\%$$

That 1% was the cover, the contents and the foreword, and every "extracted" figure came from there. That moment defined the project: an AI that reads documents is easy to build; one you can trust is not.

What it does

DataForge turns mining reports into structured, verifiable data.

  • Reads any report: digital PDFs directly, scanned pages through OCR in English, Hindi and Telugu.
  • Extracts 10 fields: mine, company, location, district, state, mineral, mining method, production, reserves and report date.
  • Shows the evidence: every value is traced back to its page and quote.
  • Flags conflicts: reports about the same mine and period are compared, and differing figures are flagged with both sources.
  • Answers questions in plain language, with page references.
  • Generates PDF and Word reports, including in Hindi and Telugu.
  • Never stores a guess: if the AI call fails, nothing is saved.

How we built it

  • Frontend: React, TypeScript, Vite, Tailwind and Radix UI, hosted on Vercel.
  • Backend: Python and FastAPI in a Docker container on Render.
  • Reading: pypdf / PyMuPDF for text layers, Tesseract OCR (eng+hin+tel) for scans.
  • Extraction: a passage selector picks the most relevant text from anywhere in the document (within 8,000 characters, using English, Hindi and Telugu cues); an AI model returns the fields as JSON; an evidence locator finds each value's page and quote.
  • Search and Ask: text is split into 1,200-character chunks, embedded (768 dimensions) and stored in PostgreSQL with pgvector; questions retrieve the 8 closest passages.
  • Model layer: provider-independent, so it runs on Google Gemini today and can switch to OpenRouter, Claude or a local Ollama model for fully offline, on-premise use.
  • Quality: 643 automated tests (489 backend, 154 frontend) and an evaluation harness that refuses to score stand-in output.

Challenges we ran into

  • Reading 1% of a report. We replaced the "first 8,000 characters" approach with passage selection across the whole document.
  • A failure that looked like success. When the AI provider was overloaded, our early version stored stand-in values under a green tick: a Hindi report was saved with invented figures. Now a failed call returns a clear error and stores nothing.
  • One invisible character. NUL bytes inside a real PDF crashed the database write, and the error arrived without CORS headers, so the site said "Cannot reach backend" while the server was healthy. We traced all five links in that chain and fixed each one.
  • Truncated answers. Reasoning models count their thinking against the output limit; a 2,000-token cap cut every reply off mid-JSON until we raised it to 8,000.
  • Big documents. The 342-page report takes about 6 minutes on a free server. The database closed the idle connection before the final save, so a correct extraction was lost; we fixed it by releasing the connection during processing.
  • Hosting. When our free trial ended, we moved the backend to Render with a Neon database in one evening, adding a single Dockerfile.

Accomplishments that we're proud of

  • 124 of 124 fields correct on 13 labelled test reports in English, Hindi and Telugu, including scanned ones.
  • Planted conflicts caught: revised figures such as 52.5 vs 49.8 million tonnes for the same mine, both traced to page 1, with no false alarms.
  • A real 342-page annual report processed on the live system.
  • An honest product: it cites its sources and refuses to invent values.

What we learned

  • A perfect score on documents you wrote yourself measures very little. Our test reports have known answers because we created them, so we built a separate real-document labelling workflow: every label pins the source URL and SHA-256 of the PDF and cites the page and quote for each value.
  • Trust comes from evidence, not confidence. Showing where a number came from matters more than the number.
  • Make failures visible. Silent failures are the most expensive kind.

What's next for DataForge

  • Real-report accuracy: label 8 to 10 real published reports and publish accuracy by field and by language.
  • Background processing so that 300-page reports never block users.
  • Reading tables, where production and reserve figures often sit.
  • A pilot with one organisation and one report type, measuring time saved against today's process.

Built With

Share this project:

Updates

Submission history