Deposition Summaries at a Litigation Firm
An example project: a 250-lawyer litigation firm drafts summaries of about 2,400 deposition transcripts a year overnight, with page:line citations checked in code, and paralegals review the drafts instead of writing summaries from scratch.
This is an example project, not a customer story. The company is made up, and every number on this page is an assumption stated so you can replace it with your own.
Deposition summaries cost about $443,000 a year less, and the build pays back in under three months
Build cost assumes engineers at $180,000 a year fully loaded. Time from other staff, such as reviewers labeling examples, is not counted. Payback is counted from go-live. See the arithmetic.
Six paralegal hours for every deposition
A litigation firm of about 250 lawyers and 90 paralegals takes or defends about 2,400 depositions a year, roughly ten every business day. A transcript arrives from the court reporter a few days after the deposition. The average one runs about 220 pages.
For every transcript, a paralegal writes a summary in the firm’s format: a topic-by-topic digest of the testimony, each point cited to page and line, followed by a list of admissions and exhibits. It takes about six hours. When a case is busy, transcripts wait a week or more in the queue, and lawyers prepare for the next deposition or a motion without a summary of the last one.
The paralegals also summarize incoming case file documents, such as pleadings, expert reports and correspondence, into a chronology for each matter. That work is smaller per document but steady.
The goal is a draft summary of every transcript ready by 8 a.m. the business day after it arrives, with every citation checked to exist, so that the paralegal’s job becomes checking and correcting the draft.
The model writes the summary; code checks every citation
The model reads sections of the transcript and writes the summary. Splitting the transcript, checking citations and delivering the draft are code the litigation support group owns.
Parse the transcript
firm's codeCourt reporters deliver transcripts as text files with page and line numbers. A parser turns each one into a list of numbered lines, so every line has a page:line address. These files are already text, so no OCR is needed for transcripts.
Split into sections
firm's codeThe transcript is split into sections of about 40 pages, at breaks between examinations or after a recess where possible. Every line keeps its page:line label in the text the model sees.
Summarize each section
modelThe model summarizes each section by topic. Every point must cite the page:line range it comes from, and any direct quotation must be marked as one. The prompt includes the firm’s topic list for the matter, which the responsible lawyer can edit.
Combine into the firm's format
modelA second call receives the section summaries, not the transcript, and merges them into one digest in the firm’s format, keeping every citation. It also lists admissions and the exhibits mentioned.
Check citations
firm's codeFor every citation, code confirms that the page:line range exists in the transcript and that any quoted words appear in those lines. Citations that fail are highlighted in the draft. Code cannot judge whether a point fairly describes the testimony. That is what the paralegal checks.
Deliver for review
existing document management systemThe draft is filed to the matter in the document management system the firm already uses, and assigned to the paralegal on the case. The final summary carries the paralegal’s name, as it does today.
The volume is small; the model's memory sets the GPU count
The arithmetic we would start from. Profiling on real traffic replaces these estimates before anything goes into a contract.
| Transcripts per business day (2,400 a year over 250 days) | about 10 |
|---|---|
| Tokens per transcript, at 220 pages and about 350 tokens per page with line numbers | 77,000 |
| Section pass: six sections, each with about 1,500 tokens of instructions and 1,200 tokens of output | about 86,000 in, 7,200 out |
| Combine pass: the section summaries plus instructions | about 8,700 in, 3,000 out |
| Case file documents: 150 a day at 15 pages and about 500 tokens per page, plus instructions | about 9,000 in, 400 out each |
| Tokens per business day | about 2.3M in, 0.16M out |
| Average rate over a 10-hour overnight window | about 63 input and 4 output tokens per second |
| Starting configuration to profile | Qwen3-235B-A22B-Instruct-2507 on four H200 GPUs (141 GB each), tensor parallel |
| Backlog of 3,000 transcripts in active matters, if the endpoint completes 60 transcripts an hour | 50 hours, about four days of daytime capacity |
The nightly load is a few million tokens, which one GPU could process many times over. The GPU count is set by the model instead. The 235B model’s weights are about 470 GB in 16-bit precision, so they are split across four H200 GPUs on one node (564 GB in total), with about 94 GB left for cache. The model is chosen for quality, because the paralegal’s review time is the largest cost on this page, and a better draft reduces it more than a cheaper GPU does.
A 220-page transcript fits in the model’s context window in one pass. The project still summarizes in sections because a model that accepts a long input does not always use all of it equally well, and section summaries make each citation easier to check. Test a single-pass summary against the section approach on the evaluation set; if it is as accurate, it is simpler.
The endpoint is set to favor throughput. It is idle during the day apart from urgent requests, such as a lawyer who needs a summary before tomorrow’s hearing, so the backlog of older transcripts can run in daytime hours. The rate of 60 transcripts an hour (about 1,600 input and 170 output tokens per second) is the assumption to check first in profiling.
How the numbers add up
| Transcript summaries today: 2,400 a year at 6 paralegal hours and $60 an hour loaded ($360 each) | $864,000 a year |
|---|---|
| Reviewing and correcting a draft with checked citations, at 2 hours ($120 each) | $288,000 a year |
| Four H200 GPUs running all year, at our reference price of $3.80 per GPU-hour | about $133,000 a year |
| Ongoing cost with the model | about $421,000 a year |
| Saving a year | about $443,000 |
| One-time build: two engineers for three months, at $180,000 a year loaded | $90,000 |
| Payback on the build, from go-live | about 2.5 months |
At these assumptions the ongoing cost of transcript summaries falls from $864,000 to about $421,000 a year, which frees about 9,600 paralegal hours. The first year also carries the build, about $90,000, which the saving covers in about two and a half months. The case file document summaries are not counted in the table, and they run on the same endpoint at no extra GPU cost.
The key assumption is review time. If reviewing a draft takes 3.5 hours instead of 2, the total is about $637,000 a year, still below today’s cost. Counting the GPUs, the project costs less than today as long as review takes under about 5 hours a transcript, so the evaluation phase must measure real review time, not just summary quality scores.
The GPU line is large here because of the model choice. If the smaller Qwen3-30B-A3B-Instruct-2507 produces drafts that take the same review time, one RTX PRO 6000 at $1.25 per GPU-hour costs about $11,000 a year instead. Compare the two on review time per transcript.
Many firms bill paralegal summary time to clients. Fewer hours then means smaller bills for that line, and whether that is a saving or lost revenue is the firm’s decision, not a property of the model. The benefit that does not show in the table is turnaround: lawyers have a summary of yesterday’s deposition before the next one in the sequence.
How the project would run
Build the evaluation set
weeks 1 to 3Take 100 past transcripts from closed matters with the summaries paralegals wrote and lawyers relied on. Five paralegals mark the points each summary must contain and the correct citation for each. Hold back 30 transcripts that no prompt is tuned on.
Compare models and approaches
weeks 4 to 5On a trial endpoint, run the candidate models with the section approach and the single-pass approach. Score citation accuracy, the share of marked points the draft covers, and paralegal review time on a sample of drafts.
Side-by-side pilot in one practice group
weeks 6 to 9In the product liability group, drafts are produced for every new transcript while paralegals still write their own summaries for the first 20. Comparing the two shows what the model misses. After that, the group’s paralegals start from the drafts and log their review time.
Firm-wide, then case file documents
week 10 onwardExtend to the other practice groups one at a time. Add case file document summaries to the matter chronology once transcript drafts are stable.
Backlog
after firm-wide launchRun older transcripts in active matters through the same pipeline in daytime hours, so lawyers have summaries for depositions that were never summarized.
What to measure
Citation accuracy
The share of citations the paralegal confirms support the point they are attached to. The code check confirms citations exist; this measures whether they are right.
Paralegal review time per transcript
Logged in the document management system. It is the number the business case depends on, so track it per practice group.
Missed points
Points the paralegal or lawyer adds that the draft left out, especially admissions. A rising count means the prompts or the section boundaries need work.
Drafts ready by 8 a.m.
The share of transcripts received the day before whose draft is filed by the morning. Misses usually mean an unusually long transcript or a failed parse.
Models to test first
Candidates from our catalog, not a ranking. The project picks one by testing them on its own labeled examples.
Qwen3-235B-A22B-Instruct-2507
The starting choice. 22B of its 235B parameters are active per token, with a native context of 262,144 tokens, so a whole transcript fits if the single-pass approach wins. It is the largest of the candidates, chosen because the quality of the draft drives review time. Apache 2.0.
Qwen3-30B-A3B-Instruct-2507
The same native context length with about 3B parameters active per token, on one GPU. The main alternative: if its drafts take the same review time, it costs about a twelfth as much to run.
Llama-3.3-70B-Instruct
A dense 70B model with a 128K-token context, enough for a long transcript section or a short transcript in one pass. Its weights are about 140 GB in 16-bit precision, so it needs two GPUs with tensor parallelism.
Sizes are total parameters as listed in our catalog. Mixture-of-experts models use only part of them for each token. Check each model's license for your use. Several, such as the Llama and Gemma licenses, carry their own terms.
When fine-tuning helps
The firm has years of summaries that paralegals wrote and lawyers relied on, paired with their transcripts. That is good training data for the firm’s format: its headings, its citation style and the level of detail its lawyers expect. A LoRA adapter trained on it may let the smaller model match the larger one on review time.
Fine-tune after the pilot, when the comparison of drafts with paralegal summaries shows what the prompted model gets wrong. Practice groups with different summary conventions can each have an adapter on the same endpoint.
When the data has to stay put
Deposition transcripts contain client confidences, privileged strategy in the topic lists, and testimony that protective orders often restrict to the lawyers on the case. The firm’s engagement letters commit it to keeping client data in its own environment. The endpoint runs inside the firm’s network, next to its document management system, so transcripts, prompts and drafts stay there.
Tell us about your project
Bring us your volumes and a sample of your data. We will tell you which models to test, what the endpoint would need, and what a performance commitment would cover. Self-service accounts can create inference endpoints to try the platform, but not on our top-tier GPU capacity.