Legal work is document-heavy. The system must first obtain reliable text and structure from contracts, pleadings, judgments, correspondence and evidence. It must then find the portions relevant to the question and preserve a path back to the original source.
This is the document pipeline. Its errors are often mistaken for model errors: an apparently weak answer may have started with a missing page, incorrect OCR, poor chunk boundary or retrieval query that never found the decisive clause.
1. The document-to-answer pipeline
A typical document-grounded Legal AI workflow has the following stages:
- Acquire: receive the original file and record its matter, source, version and access permissions.
- Parse: extract text, layout, tables, headings, page numbers and other structure.
- Normalise: correct encoding, remove repeated headers where appropriate and retain links to original page coordinates.
- Segment: divide the material into useful passages or “chunks.”
- Index: store searchable text, embeddings and metadata.
- Retrieve: find candidate passages for the user's question.
- Rerank and filter: apply relevance, jurisdiction, date, document type and permissions.
- Generate: ask the model to answer using the selected material.
- Verify: check that claims and citations match the source.
Each stage should be observable. If a lawyer cannot see what was extracted and retrieved, it is difficult to diagnose a wrong answer.
Case study: The model was blamed for a missing page
A lawyer asks whether a guarantee extends to future advances. The AI system answers that it does not. The team assumes the model misunderstood the document.
The real problem is earlier in the pipeline: page 7 of the scanned guarantee was never ingested. That page contains the future-advances clause.
Because the system records each stage, the team can see that:
- the original file contained 12 pages;
- the parser extracted only 11;
- no chunk was created for page 7; and
- retrieval therefore had no chance of finding the decisive clause.
The failure is a document-ingestion failure, not a reasoning failure.
2. OCR and document parsing
Some PDFs contain real text. Others are page images produced by scanning. Optical character recognition (OCR) converts text visible in an image into machine-readable characters. Parsing goes further by identifying structure: titles, paragraphs, lists, tables, footnotes, signatures, stamps and page relationships.
Common legal-document failures include:
- “1” read as “I” in a section or date;
- columns merged in the wrong order;
- a table row separated from its heading;
- footnotes inserted into the main sentence;
- handwritten amendments omitted;
- repeated headers treated as substantive text;
- tracked changes or comments ignored; and
- an annexure attached to the wrong document.
Preserve the original file and page images. Store the extracted text with page and coordinate references so a reviewer can compare it with the source. For critical fields (amounts, dates, party names, statutory sections and limitation events) consider deterministic validation or human confirmation.
Example: One OCR error changes the legal conclusion
A scanned demand notice states that payment was due on 11 June. OCR reads the date as 17 June. The AI then prepares a chronology and calculates the limitation period from the wrong date.
Other small OCR errors can be equally serious:
- “₹1,00,000” read as “₹10,000”;
- “Section 17(1)” read as “Section 171”;
- “shall” read as “shall not”; and
- a party name read incorrectly, causing documents to be attributed to the wrong person.
Case study: The broken damages table
A claim schedule contains four columns: invoice number, due date, amount paid and balance outstanding. During extraction, the final two columns are merged and several amounts shift into the wrong rows.
The model accurately sums the extracted figures and produces the wrong claim amount. The arithmetic is correct; the table reconstruction is not. For tabular evidence, reviewers should inspect the reconstructed table against the page image before relying on calculated totals.
Example: The missing handwritten amendment
A typed agreement allows termination on 30 days' notice. A handwritten amendment on the signature page changes this to 90 days and is initialled by both parties. The parser extracts only the typed text.
The model may perform perfectly on the text it receives and still reach the wrong conclusion. Critical scans should therefore be reviewed for handwriting, stamps, marginal notes and alterations that ordinary text extraction may miss.
3. Multimodal material
Multimodal models can process more than plain text, including images, audio and sometimes video. They can help interpret signed pages, screenshots, photographs, diagrams, bank statements, handwritten notes and recordings.
That ability does not remove evidential concerns. A transcript may misidentify a speaker; a model may infer text that is not legible; image resizing may obscure a notation; and file metadata may be lost. For evidential material, retain the original, preserve chain-of-custody information, document transformations and distinguish machine-generated descriptions from established facts.
Case study: Building a chronology from mixed evidence
An investigation file contains:
- a WhatsApp screenshot;
- an audio recording of a meeting;
- a photographed handwritten ledger;
- a bank statement; and
- a signed agreement.
The system is asked to prepare a chronology. A responsible output should distinguish:
- extracted fact: the bank statement records a transfer on 14 April;
- machine transcription: the audio appears to contain the words “payment next week”;
- machine inference: a person visible in the screenshot may be the respondent; and
- disputed interpretation: the handwritten ledger entry may refer to the same transaction.
Combining all four categories into one confident narrative would overstate what the evidence proves.
4. Chunking legal documents
Search systems usually divide documents into smaller passages. This is called chunking. A chunk must be small enough to retrieve precisely but large enough to preserve meaning.
Fixed-size chunks are simple but can separate a proviso from its section or a definition from the operative clause. Structure-aware chunking follows the document:
- clauses and subclauses for contracts;
- paragraphs and headings for judgments and pleadings;
- sections, provisos and explanations for legislation;
- messages and quoted threads for email; and
- events, exhibits and witnesses for a case chronology.
Overlap can repeat some text between neighbouring chunks so a sentence near a boundary retains context. Parent-child retrieval can locate a precise paragraph and then provide its surrounding section. Metadata should record the document, page, clause, date, jurisdiction, confidentiality level and matter permissions.
Example: The rule is retrieved but the exception is lost
A statutory provision is divided into three fixed-size chunks:
- the main prohibition;
- the proviso creating an exception; and
- the explanation defining when the exception applies.
A search retrieves only the first chunk. The AI accurately states the prohibition but omits the exception.
Structure-aware chunking could keep the section, proviso and explanation together, or parent-child retrieval could supply the full provision after locating the relevant paragraph.
5. Embeddings
An embedding model converts a passage into a vector: a list of numbers representing patterns in its meaning. Passages with similar meaning tend to have vectors that are closer in the model's mathematical space.
For example, “May the buyer terminate without breach?” and “termination for convenience” may be semantically related despite having few words in common. Embedding search can therefore retrieve conceptually related drafting that keyword search may miss.
Example: Semantic similarity and legal difference
An embedding system may place the following passages close together:
- “The buyer may terminate for convenience.”
- “The buyer may not terminate for convenience.”
Most words and concepts are shared, but the legal effect is opposite. Similarity search helps locate candidates; it does not replace reading the operative language.
Embeddings are not legal analysis. They may blur distinctions that matter in law: “shall” and “may,” claimant and respondent, permitted and prohibited, current and repealed. They also inherit limitations from the material on which the embedding model was trained.
6. Keyword, vector and hybrid search
6.1 Keyword search
Lexical search finds words and phrases. It is particularly valuable for case names, citation strings, defined terms, section numbers, dates and unusual language. Exact search can outperform semantic search when the wording itself matters.
6.2 Vector search
Vector search compares the embedding of the question with stored passage embeddings. A vector database or vector-capable search engine stores vectors together with identifiers and metadata. It stores a mathematical representation, not “meaning” in a legally authoritative sense.
6.3 Hybrid search, filters and reranking
Hybrid search combines lexical and vector results. Metadata filters can restrict results to the correct matter, jurisdiction, court, date, document type or confidentiality level. A reranker then scores a smaller candidate set for relevance to the exact question.
For legal work, this combination is often stronger than relying on a vector database alone. A query about a statutory section may need an exact citation match, a semantic match for the legal concept and a filter excluding superseded versions.
Case study: Why hybrid search is necessary
A research database contains:
- the current statute;
- a repealed version of the statute;
- a recent domestic judgment;
- a foreign judgment using similar language;
- an internal research note; and
- general commentary.
The question asks whether “Section 24(3)” permits a particular disclosure.
A strong search process may require:
- an exact keyword match for “Section 24(3)”;
- semantic retrieval for passages discussing the same disclosure concept;
- a jurisdiction filter excluding foreign law;
- a date or version filter excluding the repealed text; and
- reranking that places primary authority above commentary.
No single retrieval method handles all of these requirements reliably.
7. Retrieval-augmented generation
Retrieval-augmented generation (RAG) means retrieving relevant information and supplying it to a generative model as context for an answer. The sources may be uploaded matter documents, an internal precedent bank, legislation, case law or results returned by an approved external service.
A simplified RAG request is:
- convert the user's question into one or more search queries;
- retrieve candidate passages;
- apply access controls, filters and reranking;
- place the selected passages, with source identifiers, into the model context;
- instruct the model to answer from those passages and identify gaps; and
- link each material claim to its source.
RAG reduces dependence on model memory, but it does not force correctness. The right passage may not be retrieved; an incomplete passage may omit an exception; or the model may misread a correct source. Retrieval and generation must therefore be evaluated separately.
Case study: The wrong annexure, correctly analysed
The main agreement refers to “Pricing Schedule B.” Two versions of Schedule B exist in the matter folder. The retrieval system selects the older version because its text is more similar to the user's question.
The model correctly analyses the retrieved schedule and gives a precise answer. The answer is still wrong because the source version is wrong.
Document identity, execution status, date and version should therefore be part of retrieval metadata and visible in the final citation.
8. Grounding, citations and verification
Grounding means connecting an answer to supplied evidence. A grounded contract finding should identify the document version, clause and supporting words. A grounded research proposition should identify the authority and the passage that actually supports that proposition.
Citation display and citation correctness are different. A system can attach a real case to a proposition the case does not support. Verification should test:
- that the source exists and is the intended version;
- that quoted text matches the source;
- that the cited passage supports the proposition;
- that exceptions and surrounding context were not omitted;
- that the authority remains current and applicable; and
- that the system did not silently rely on an uncited source.
Some checks can be automated: names, dates, exact quotations, citation syntax and whether a source identifier resolves. Legal validity, treatment, materiality and application to the facts still require appropriate professional review.
Example: A correct citation used incorrectly
An AI research note cites a real judgment and links to the correct paragraph. The paragraph concerns procedural delay, but the note uses it to support a substantive rule on contractual waiver.
Three different checks are required:
- Does the cited source exist?
- Is the quoted or linked passage accurate?
- Does that passage support the proposition for which it is cited?
A system can pass the first two checks and still fail the third.
9. Evaluating the pipeline
Test ingestion with known pages, tables and fields. Test retrieval with questions for which the relevant passages are known. Useful retrieval measures include whether the correct passage appears in the top results and how much irrelevant material accompanies it.
Then test generation for factual support, citation correctness, completeness and appropriate uncertainty. When an answer fails, classify the stage: parsing, chunking, query formation, retrieval, reranking, generation or verification. Without this separation, teams may change the model when the real problem is a missing page.
Diagnostic exercise: Where did the failure occur?
A system gives the wrong answer about a termination clause. Possible causes include:
- the amendment was never uploaded;
- OCR failed to extract the relevant line;
- the clause and its exception were split into separate chunks;
- the search query used the wrong terminology;
- a matter-permission filter excluded the amendment;
- the reranker placed an older clause above the current one;
- the model misread a correctly retrieved passage; or
- the citation checker confirmed the source existed but did not test whether it supported the conclusion.
The corrective action depends on the stage. Changing the language model will not fix a missing file, poor OCR or defective permissions.