EliconStart a project →
← ALL WORK

CASE 05

8 weeks

RAG Knowledge Base for a Legal Firm

Associates find precedent in minutes, not hours, with every answer cited.

  • Python
  • FastAPI
  • Anthropic
  • pgvector
  • Postgres
Sector
Legal services
Team
9 partners, 20+ associates
Corpus
~40,000 documents, 20 years
Engagement
Fixed scope, 8 weeks
Access
SSO, full audit logging

A mid-size firm had two decades of briefs, memos and executed contracts that only existed as institutional memory. We turned the archive into a searchable, citable knowledge base where every answer resolves to the exact paragraph it came from — and where an uncited answer is structurally impossible.

THE PROBLEM

What was going wrong.

Associates spent hours grepping through thousands of briefs, memos, and contracts to answer partner questions. Results were inconsistent and hard to audit.

The archive was a document management system with folder names that made sense to whoever created them in 2011. Search was filename and metadata only, so finding the right precedent depended on knowing it existed.

The real cost was seniority-shaped. Partners asked associates; associates asked the one senior associate who had been there longest; that person became a lookup service. When they were on holiday, research slowed to a crawl.

Two partners had independently tried consumer AI tools on redacted documents and got confident, fluent, wrong answers. The firm's appetite for anything that could not show its sources was correctly zero.

CONSTRAINTS WE WORKED UNDER

  • ·Nothing leaves the firm's environment unlogged — client confidentiality is the entire business.
  • ·Every answer must cite a retrievable passage. An answer without a source is a liability, not a feature.
  • ·Documents span twenty years of formats: clean DOCX, scanned PDFs, and faxes that were scanned twice.
  • ·Adoption had to survive partner scepticism, so the first demo had to be run on the hardest question they could think of.

WHAT WE DID

The short version.

  1. 01

    Built an ingestion pipeline with careful chunking so citations always resolve to exact paragraphs.

  2. 02

    Chose Anthropic for long-context synthesis with aggressive groundedness prompts — no confident answers without a cite.

  3. 03

    Added a reviewer UI where partners can flag bad answers; flags feed a weekly retrieval-tuning loop.

  4. 04

    Locked the whole thing behind SSO with full audit logs for compliance.

ARCHITECTURE

How it's built.

01

Ingestion & OCR

Document watcher on the DMS, format detection, OCR for the scanned tail of the corpus, then structural parsing that preserves clause and paragraph boundaries. Every chunk keeps a pointer back to document, page and paragraph so a citation is a location, not a guess.

02

Structure-aware chunking

Legal documents have structure worth respecting — numbered clauses, defined terms, schedules. Chunking follows that hierarchy instead of a fixed token window, with parent-clause context attached to each chunk so a subclause never gets read in isolation.

03

Retrieval & synthesis

pgvector for dense retrieval with metadata filters on matter type, jurisdiction and date, then a long-context synthesis pass that must quote before it concludes. The prompt contract requires a passage ID per assertion; responses failing schema validation are regenerated, not shipped.

04

Reviewer UI

Answers render with each claim linked to its source passage, expandable inline. Partners flag bad answers with a reason; flags queue into a weekly review where we tuned retrieval rather than arguing with the model.

05

Access & audit

SSO against the firm's identity provider, matter-level permissions mirrored from the DMS, and an append-only audit log of every query, every document surfaced and every answer produced.

KEY DECISIONS

What we chose, and what it cost.

Long-context synthesis over aggressive summarization

WHY

Legal reasoning depends on surrounding language. Pre-summarizing chunks to save tokens destroys exactly the nuance that makes an answer correct.

TRADE-OFF

Higher token cost per query. Justified in one line of arithmetic: an associate hour costs more than a month of inference at their query volume.

Structured output with mandatory passage IDs

WHY

Prompting a model to 'always cite' is a suggestion. Requiring a schema where each assertion carries a passage ID, and rejecting responses that fail validation, is enforcement.

TRADE-OFF

Occasional regeneration and slightly stiffer prose. The firm considered stiff-and-sourced a strict improvement over fluent-and-unverifiable.

Mirrored DMS permissions rather than a new access model

WHY

Matter-level confidentiality already existed and was already audited. Inventing a second permission model would have created two sources of truth about who may see what.

TRADE-OFF

A sync dependency on the DMS, and permission changes propagate on a delay measured in minutes rather than instantly.

THE HARD PARTS

What nearly broke it.

The scanned tail

About 15% of the corpus was scanned paper, some of it poorly. Naive OCR produced chunks that retrieved well and cited to garbage. We added a per-document OCR confidence score and excluded low-confidence documents from the index entirely, surfacing them as 'exists, not indexed' rather than silently returning nonsense.

Defined terms

A contract defining 'Territory' in clause 1.4 changes the meaning of every later mention. Flat retrieval got this wrong constantly. Attaching the definitions section to every chunk from the same document fixed a whole class of subtly wrong answers.

The partner demo

The first demo question was deliberately obscure — a jurisdictional carve-out from a 2014 matter. The system found it and cited the clause. That single result did more for adoption than the following two weeks of engineering.

HOW IT RAN

The timeline.

  1. 01

    Corpus audit

    Week 1

    Sampled the archive, measured format distribution and OCR quality, and established what fraction of the corpus was realistically indexable before promising anything.

  2. 02

    Ingestion pipeline

    Weeks 2–4

    Built parsing, OCR, structure-aware chunking and the citation-resolution guarantee. Ran full-corpus ingestion twice as the chunking strategy changed.

  3. 03

    Retrieval & synthesis tuning

    Weeks 5–6

    Evaluated against a partner-written question set with known correct sources, tuning until the right passage appeared in the top results consistently.

  4. 04

    UI, SSO, audit, rollout

    Weeks 7–8

    Reviewer interface, identity integration, audit logging, then a staged rollout starting with the associates who had the most to gain.

OUTCOME

What changed.

Half a day → <10 min

Typical research task turnaround

40k

Documents indexed with paragraph-level citations

20 yrs

Of archive made searchable, including scanned paper

0

Answers shipped without a resolvable source

Schema-enforced, not prompt-requested.

Research tasks that took half a day now take under ten minutes. Partners report higher confidence because every answer links to the underlying passage.

The senior associate stopped being a human index. That was the stated goal in week one and the thing the firm actually noticed by week ten.

Junior associates benefited most. The system surfaced precedent they did not know existed, which compressed the part of their development that had previously been pure tenure.

STACK

What it's made of.

BACKEND

  • Python
  • FastAPI
  • Postgres

AI

  • Anthropic
  • pgvector
  • Structure-aware chunking
  • Structured outputs

INGESTION

  • OCR pipeline
  • DMS watcher
  • Confidence scoring

SECURITY

  • SSO
  • Matter-level ACLs
  • Append-only audit log

HANDOVER

What they kept.

  • Ingestion runbook covering re-indexing, new document types and OCR failure handling.
  • The partner-written evaluation set, maintained so retrieval quality stays measurable as the corpus grows.
  • Access and audit documentation prepared for their compliance review.