Contracts, manuals, policies and reports become answerable. We parse layout, tables and scans, keep the structure, and return answers your reviewers can verify in one click.
Teams that answer questions by reading long documents
Document Q&A is for content where the answer lives in a specific clause, table or page, and where being roughly right is not good enough.
Example: a legal operations team fielding "what is our notice period with this supplier?" across hundreds of agreements. Example: a field-service organisation whose engineers search 400-page maintenance manuals on a phone. Example: a compliance function checking which policy version applied on a given date. In each case the user needs the passage, not a paraphrase, and the system has to say "not found" rather than guess. Our glossary entry on hallucination explains why that last point matters so much.
Outcomes we design for
Answers quote the passage and link to the page or clause
Tables, scans and multi-column layouts are read correctly
"Not in the documents" is a first-class answer
Questions can span many documents and versions
Every answer is logged with its sources for audit
Parsing quality is measured on your files before build
How it works
Structure is captured once at ingest, then carried into every citation
Top: each document version is parsed and chunked with its page and heading path attached. Bottom: a question retrieves the best passages, the model answers from those passages alone, and the citation resolves back to the exact page and clause.
The highlighted boxes are where document Q&A differs from ordinary RAG. Chunking by structure means a clause is never cut in half and a table row never loses its header. The answer stage is restricted to the retrieved passages and must either cite or decline. Everything else follows the enterprise RAG architecture, including permissions and evaluation.
What breaks
Document types that defeat naive RAG, and what we do about them
Most failed document Q&A pilots fail at parsing, not at the language model. These are the cases we test for in the first week.
Document type
What goes wrong with a plain text extract
How we handle it
Scanned PDFs and faxes
No text layer; skewed or faint pages produce garbage that still gets indexed
OCR with per-block confidence; low-confidence pages are queued for review and excluded until approved
Tables (rate cards, schedules, financials)
Rows split across chunks and headers lost, so "what is the fee for tier 2?" returns the wrong cell
Table extraction to row-wise text with the header repeated per row; cell references kept for citation
Multi-column layouts
Reading order scrambled across columns; sentences interleave
Layout detection that orders blocks column by column before chunking
Cross-references ("see Schedule 3", "as defined in clause 1.1")
The referenced text is elsewhere, so the answer is incomplete or misleading
Definitions and referenced sections linked at ingest and retrieved together with the citing passage
Amended contracts and policy versions
Old and new text both retrieved; the model picks one at random
Version and effective-date metadata; filters default to the current version with an option to ask about a date
Slides and diagrams
Text inside images is invisible; speaker notes ignored
OCR on slide images, notes indexed, image captions generated where useful
Spreadsheets
Formulas, hidden sheets and merged cells produce nonsense text
Sheet-aware ingestion using computed values, with the sheet and cell range as the citation
For high-volume extraction of fields rather than questions, the document processing solution is usually the better tool. The two are often combined: extract the structured fields, then answer free-form questions over the rest.
What we deliver
A document Q&A system, not a demo
Parsing pipeline
Layout analysis, table extraction and OCR with confidence scoring, tuned on a sample of your real files. Parsing accuracy is reported before we build anything else.
Resolvable citations
Each answer links to the page, heading path and clause or cell it came from. A viewer opens the source with the passage highlighted.
Comparison and batch modes
Ask the same question of fifty documents and get a table of answers with citations, or compare two versions of one document clause by clause.
Permissions and audit
Document-level access control enforced inside retrieval, and a log of every question, answer and source for compliance review.
Evaluation set
Questions with known answers and locations, written with your reviewers. Parsing, retrieval and answer quality are scored on every change.
Interface and API
A web app with a document viewer, or an API that drops into your case system, intranet or Salesforce. Built with the patterns from LLM app development.
How we work
Parsing trial first, then build in measured increments
Parsing trial
One week. You send 50–200 representative files. We report what parses cleanly, what needs OCR and what needs special handling, with a sample of extracted text to check.
Question set
Your reviewers write 100–200 questions with the correct answer and its location. This becomes the yardstick for every later decision.
Ingest and retrieve
Structure-aware chunking, embeddings chosen with our embeddings strategy, hybrid retrieval and reranking tuned until retrieval scores plateau.
Answer and cite
Prompting restricted to retrieved passages, citation checks, "not found" behaviour and version handling. Comparison and batch modes where scoped.
Pilot and launch
Two to four weeks with real users and real questions. We fix what the logs reveal, then hand over code, runbooks and the evaluation harness.
A note on scanned archives
OCR quality on old or poorly scanned material varies widely, and no amount of retrieval tuning fixes text that was never extracted. We give you the parsing numbers from the trial week, and for archives with many unreadable pages we recommend a review queue or re-scanning before indexing. Being told this in week one is cheaper than discovering it in week ten.
PDF (native and scanned), DOCX, PPTX, XLSX, HTML, Markdown and email. Scanned pages go through OCR with a confidence score per block, and low-confidence pages are flagged for human review rather than silently indexed.
How accurate are the citations?
Every chunk carries its page number, heading path and, where available, clause or table reference from the parser. The answer can only cite passages it was given, and an output check rejects any citation that does not resolve. The remaining risk is a wrong passage ranked first, which the evaluation set is designed to catch.
Can it compare two versions of a document?
Yes. We ingest each version separately, keep a version field in metadata and offer a comparison mode that retrieves the same section from both and asks the model to state the differences with citations to each. It is a common request in contract analysis.
How is this different from uploading a PDF to a chat tool?
A chat tool reads one file at a time into the context window and forgets it afterwards. Document Q&A indexes thousands of files, keeps structure and permissions, answers across documents and logs every answer with sources so it can be audited and improved.
How long does a document Q&A build take?
Typically 6–10 weeks for a first release over one document family, such as contracts or technical manuals. Parsing quality on your actual files is the main variable, so we run a one-week parsing trial before committing to a timeline. Send us a sample set.
Ready to make AI work in production?
Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.