Deposition Analysis RAG System for a Legal Tech Platform
How we built a retrieval-augmented generation system over a legacy deposition database — with inconsistency detection, natural-language Q&A, report generation, and a full ETL pipeline from a .NET source.
Services
Key Results
- ✓Natural-language Q&A over a legacy deposition corpus, grounded in source documents with citations
- ✓Inconsistency detection across depositions, powered by a purpose-built reasoning workflow
- ✓Consumer-facing and admin interfaces delivered end-to-end in three months
- ✓On monthly retainer for ongoing model and feature evolution
The situation
A legal technology platform had spent years building a database of attorney depositions in a legacy .NET system. The data was valuable — it contained detailed testimony records useful for case research, inconsistency analysis, and litigation strategy. But it was locked inside a schema that predated modern search, and accessing it meant knowing exactly what to look for.
They wanted to unlock that corpus for their users: let attorneys ask natural-language questions, surface contradictions across depositions, and generate structured reports — without rebuilding the underlying database or abandoning the data that was already there.
What we built
A retrieval-augmented generation system running on AWS, with a full ETL pipeline feeding it from the legacy source.
The ETL pipeline reads from the .NET database, normalizes and chunks the deposition records, generates embeddings, and loads the output into a retrieval index. The pipeline handles the shape of legacy data — inconsistent formatting, varying record structures — and produces clean, chunked input that the retrieval layer can work with reliably.
On top of that, two distinct AI workflows:
Q&A over depositions. Attorneys ask natural-language questions and receive answers grounded in specific deposition excerpts, with citations back to the source record. Claude Sonnet handles the retrieval-grounded generation for this workflow.
Inconsistency detection. A separate orchestration workflow identifies contradictions across deposition records and flags them for attorney review. This task requires more complex multi-document reasoning, so it uses Claude Opus — the harder the reasoning requirement, the more capable the model.
Both workflows feed into report generation. The platform also delivers a consumer-facing interface for end-user queries and a separate admin interface for platform management and workflow configuration.
Decisions that mattered
Two models, not one. Sonnet and Opus serve different jobs here. Sonnet is fast and accurate for retrieval-grounded Q&A where the answer is directly supported by a source chunk. Opus is reserved for inconsistency detection, where the system needs to reason across multiple documents and surface contradictions that are not obvious at the sentence level. Using Opus for everything would be slower and more expensive without improving Q&A quality. Using Sonnet for everything would produce weaker inconsistency detection.
ETL before RAG. The quality of a retrieval system depends entirely on the quality of its input. Before writing a single line of orchestration code, we designed the ETL pipeline to handle the edge cases in the legacy .NET data — varying record formats, encoding issues, incomplete fields. The retrieval layer only works reliably because the pipeline feeding it is boring and rigorous.
Retrieval-grounded outputs only. Every answer the Q&A system produces cites the specific deposition record it drew from. The system does not synthesize across documents without attribution, and it does not fall back to the model's general knowledge when retrieval comes up short. If the answer is not in the corpus, the system says so.
Separate consumer and admin surfaces. The consumer UI is optimized for attorneys using the system in the course of casework — clean, query-focused, citation-forward. The admin UI serves the platform's internal team: managing ingestion, monitoring workflows, configuring the inconsistency-detection pipeline. Blending these into a single interface would have made both worse.
Outcome
The platform delivered three months from kickoff: ETL pipeline, retrieval index, Q&A workflow, inconsistency-detection workflow, report generation, consumer UI, admin UI.
The deposition corpus that was previously searchable only by those who knew its schema is now accessible through natural language. Attorneys can ask questions and receive answers with source attribution. Inconsistencies that would require manual cross-reference can be surfaced systematically.
The engagement is on a monthly retainer. Model versions change, new Bedrock capabilities become available, and the platform's feature set continues to evolve — the retainer structure means that evolution is planned and budgeted, not reactive.
Working with us
The engagement started with an architecture review focused on the retrieval design and ETL strategy. Legacy source data is the hardest part of most RAG projects — getting that pipeline right before building the AI layer determines whether the system is usable in production or impressive only in demos.
If you have a legacy data corpus and want to build reliable AI retrieval over it — not a proof of concept, but something that ships and holds up — let us know.