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.
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.
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.
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.
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 service is usually the better tool. The two are often combined: extract the structured fields, then answer free-form questions over the rest.
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.
Each answer links to the page, heading path and clause or cell it came from. A viewer opens the source with the passage highlighted.
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.
Document-level access control enforced inside retrieval, and a log of every question, answer and source for compliance review.
Questions with known answers and locations, written with your reviewers. Parsing, retrieval and answer quality are scored on every change.
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.
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.
Your reviewers write 100–200 questions with the correct answer and its location. This becomes the yardstick for every later decision.
Structure-aware chunking, embeddings chosen with our embeddings strategy, hybrid retrieval and reranking tuned until retrieval scores plateau.
Prompting restricted to retrieved passages, citation checks, "not found" behaviour and version handling. Comparison and batch modes where scoped.
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.
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.
Clause extraction, obligations and risk flags across an agreement portfolio.
ReadExtract and classify fields from large volumes of invoices, forms and correspondence.
ReadWhy the way a document is split decides what the model can find.
ReadThe full picture: RAG, copilots and migration from legacy knowledge bases.
ExplorePDF (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.
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.
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.
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.
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.
Tell us what you are trying to do, which systems are involved and what is in the way. We reply within one business day with an opinion and a suggested next step.