Deposition transcripts look like the easiest documents in litigation: monospaced text, numbered lines, one witness talking. In practice they are far harder to get right for legal AI than they look, because the thing that makes a transcript useful — its page:line coordinate system — is exactly what generic PDF-to-text tooling throws away. This cookbook walks through the format, the failure modes, a working extraction schema, and how to build the pipeline with Reducto's Parse and Extract APIs.

The deposition transcript format

U.S. deposition transcripts typically follow the format standardized by the federal Judicial Conference and widely adopted by court reporters (formatting guide). The load-bearing conventions:

• 25 lines of text per page, double-spaced. Page numbers do not count toward the 25.

• Q and A designations sit at the left margin, marking examiner questions and witness answers.

• The title page carries the case caption, and the appearances of counsel begin on the title page.

• Each volume includes an index of examinations — direct, cross, redirect — showing the examination types and the page where each begins (formally, on whose behalf the witness was called); deposition indexes conventionally also name the examining attorney.

One more structural fact matters: under FRCP 30(e), if review is requested before the deposition is completed, the deponent gets 30 days after being notified that the transcript is available to review it and, if there are changes in form or substance, to sign a statement listing the changes and the reasons for them. That errata sheet is part of the record. Any system that ingests transcripts without ingesting errata is quoting testimony the witness may have formally amended.

Why transcripts are hard to parse — and what "good" means

The core idea of this cookbook is simple: page:line is the citation coordinate system of a deposition, and extraction must preserve it — not strip line numbers as noise. A lawyer does not cite "the part where the witness discussed the email." They cite 142:17–143:4. An extraction pipeline that returns clean prose with the line numbers removed has destroyed the address scheme the legal workflow is built on. "Good" parsing here is not fluent text; it is text whose every span can be mapped back to a page and line.

That single requirement drives the other failure modes:

• Q/A attribution across page breaks. A question can start on line 24 of one page and its answer begin on line 1 of the next. Naive page-by-page processing orphans the answer or attributes it to the wrong speaker. Attribution gets harder still during colloquy — objections and back-and-forth between counsel interleaved with testimony — where the Q/A rhythm is interrupted and speaker labels shift.

• Word-index pages mimic content but are noise. The concordance at the back of a transcript lists essentially every substantive word (stop words excluded) with its page:line occurrences. To a text extractor it looks like dense, citation-rich content; to a RAG system it is pure poison — retrievals that "match" the query because the index contains essentially every substantive word. These pages must be identified structurally and excluded.

• Errata create a second source of truth. Once an errata sheet exists, the transcript alone is no longer authoritative. The pipeline needs the original testimony, the changes, and the stated reasons — linked to each other by page:line.

Traditional OCR makes these failures structural rather than incidental: flat text dumps treat marginal line numbers as noise to strip — throwing away the page:line address scheme in the act of "cleaning" the text — and merge the word index into testimony while losing Q/A attribution across page breaks. Template and zonal approaches offer no way around it, because a transcript's content is free-flowing dialogue, not fixed fields at known coordinates. The job requires layout-aware parsing that treats line numbers, speaker designations, and page structure as data to preserve rather than artifacts to remove.

What to extract

A schema that serves litigation-support and legal-AI workflows:

• Witness and appearances. The deponent's name, and counsel appearances from the title page onward — who appeared for which party.

• Examinations. An ordered list of examination segments: examiner, examination type (direct, cross, redirect), and the page:line span where each begins and ends. The volume's index of examinations gives you a built-in cross-check.

• Q/A pairs with page:line anchors. Each question and its answer, with the speaker attribution and the start and end coordinates of both. The page:line anchor is the citation — and it pairs naturally with Reducto's extraction citations, which tie every extracted value back to its location in the source document, so an attorney can audit any extracted answer against the underlying page.

• Exhibit references. Every point where an exhibit is marked or discussed, with its identifier and the page:line where it enters the testimony.

• Errata entries. For each change: page, line, original text, amended text, and the deponent's stated reason.

Building it with Reducto

Parse first, with layout fidelity. Run the transcript through Parse. Reading order and layout preservation are what matter here: the line-number gutter, the Q/A designations at the margin, and the 25-line page structure all need to survive into the parsed output rather than being flattened into a paragraph soup. The parse best-practices guide covers the configuration choices that affect layout-sensitive documents like this.

Then Extract against your schema. Point Extract at the parsed document with the schema above — witness, appearances, examinations, Q/A pairs, exhibits, errata. Enable citations so each extracted field carries a verifiable pointer back to the source. For deposition work this is not a nice-to-have; it is the audit trail.

Chunk on testimony boundaries for RAG. If you are building retrieval over transcripts, chunk on Q/A-pair or examination boundaries rather than fixed token windows, and keep the page:line range in each chunk's metadata. Reducto's chunking methods let you control segmentation so chunks align with the document's real structure. A chunk that carries "142:17–143:4" in its metadata lets the downstream model cite testimony the way a lawyer would.

For related legal pipelines, see the redlined legal contracts cookbook — pulling every tracked revision out of a contract as structured data — and the law review article cookbook, which splits a long legal document into sections and extracts any part of it.

Validating accuracy

The format's rigidity is a gift: it gives you structural invariants to test against.

• Line-count check. Standard-format pages carry 25 numbered lines. Pages that parse to a different count deserve inspection — they are either non-standard pages (title, index, certificate) or parsing errors.

• Q/A pairing audits. Every Q should have an A (or an objection sequence) following it; runs of unpaired designations usually mean speaker attribution broke at a page boundary or during colloquy.

• Page:line spot-checks. Sample extracted Q/A pairs and confirm their anchors against the original PDF. With extraction citations enabled, this check is a lookup, not a hunt.

• Index reconciliation. Compare your extracted examination list against the transcript's own index of examinations.

Compliance and deployment

Deposition transcripts are not part of the public court record by default — under FRCP 5(d) they are not filed until used in the proceeding — and are frequently covered by protective orders. Reducto supports Zero Data Retention on Growth plans and above, and offers VPC and on-prem deployment for firms and legal-tech vendors whose data cannot leave their environment. See reducto.ai/industries/legal for the legal-industry overview.

FAQ

Can I keep page:line citations in my RAG chunks?

Yes — that is the recommended pattern. Chunk on Q/A or examination boundaries and store each chunk's page:line range as metadata, so retrieved passages can be cited in the standard litigation format.

How do word-index pages get excluded?

Structurally. Index pages differ from testimony pages in layout — columnar word lists rather than 25 lines of Q/A text — so a layout-aware parse distinguishes them, and they can be filtered before extraction and chunking instead of leaking into your corpus.

What about errata sheets?

Treat them as first-class documents. Extract each change with its page, line, original text, amendment, and reason, and link entries to the testimony they modify so downstream systems always see the amended record alongside the original.