Designing a document review workflow that survives contact with volume

The companion document review overview explains the basic stages of review and the principal technologies available to support them. The level below is the operating design: how a team turns a potentially large collection into batches, instructions, quality controls, and production decisions that reviewers can apply consistently.

A document review workflow succeeds when the reasons for its decisions remain visible after the first few batches. The reviewer should be able to identify what the batch represents, which coding decisions control, how close calls are handled, and where an unresolved question enters the escalation path. That structure matters more than the nominal size of the queue.

Build the workflow before loading documents into a queue#

Several decisions precede a reviewer’s first classification. The team decides how documents will be grouped, how large each batch will be, whether a batch represents a custodian or a particular subject, and whether families, attachments, or near-duplicate documents remain together. Each choice affects both throughput and the consistency of coding decisions.

Those choices also need to be recorded rather than left to platform defaults. A batch can be organized by custodian, family, concept cluster, or date, but each method answers a different question. Custodian-based batches place the coding decisions in the context of a person’s files; family-based batches preserve the relationships among messages and attachments; concept clusters test the usefulness of search terms and issue framing; and date-based batches can reveal how a matter developed over time.

Batch size presents a related tradeoff. Smaller batches make it easier to test instructions, monitor reviewer behavior, and redirect work when a new issue appears. Larger batches can reduce repeated setup work and preserve broader context, but they also make drift harder to detect. A useful design keeps batches coherent, gives each batch a clear review objective, and uses a size that the team can quality-control during the pass rather than only after it.

A batch should be a controlled unit of work, not merely a convenient segment of a collection.

Use a coding layout that reviewers can actually remember#

The coding layout should distinguish responsiveness, privilege, confidentiality designations, and substantive issue codes. These categories answer different questions. Responsiveness asks whether a document is within the defined scope of discovery; privilege asks whether it contains protected material; confidentiality identifies sensitivity separately from legal protection; and issue codes capture the subjects that support later analysis.

Reviewers often need several binary decisions followed by an optional issue code. Keeping the panel small supports that pattern. When every substantive issue receives a separate code, reviewers must decide which code applies, whether more than one applies, and how closely the document must match the issue definition. Those choices multiply opportunities for disagreement even when the underlying issue is the same.

Each code should therefore have a defined trigger, a defined treatment when it overlaps another code, and a stated relationship to responsiveness. Codes also need a route for documents that raise a possible issue without clearly belonging to it. An “other” or “potential issue” designation can preserve that possibility, provided its use is reviewed; an unconstrained catch-all can become a way to avoid a difficult coding decision.

Privilege, confidentiality, and responsiveness should remain conceptually separate. A confidential document may also be responsive, and a responsive document may contain privileged material. Combining those judgments in one label obscures both the review decision and the later handling decision.

Turn the review protocol into operational instructions#

Production disputes often turn on what the coding instructions actually required. A review protocol should define what responsive means in the context of this matter, how families are treated, what reviewers should do with close calls, and how questions are escalated and answered for the entire team.

Responsiveness requires concrete examples. Rather than stating that the team will search for documents relevant to a project, the protocol can identify the communications, records, and attachments that fall within that description. It can also explain what is outside the request and how to distinguish merely related material from material that actually responds to the defined issue.

Family treatment should be explicit. Options include reviewing and coding every family member separately, coding at the family level, or applying a default to members that add no substantive content. Whichever approach is used, the protocol should address how attachments, forwarded messages, duplicate text, and embedded files are treated. Reviewing a family member in isolation can change a judgment that would be different when the complete conversation is available.

Close calls need a defined path. The instructions can direct reviewers to flag a document, apply a documented coding treatment, and send the question through a single escalation channel. A knowledgeable reviewer or attorney can then answer once, and the answer can be incorporated into the protocol for later batches. Allowing each reviewer to resolve uncertainty independently creates invisible divergence across the collection.

The protocol should also establish how answers become part of the shared record. A written clarification, a protocol amendment, and a batch-level precedent can serve different purposes. The important point is that the answer reaches the reviewers who need it and remains available when the team revisits earlier work.

Design the first pass as a managed workflow#

The first pass should begin with a controlled start rather than an unrestricted release of all documents. A limited set of batches can test the instructions, reveal ambiguous code definitions, and expose problems with family handling before the team repeats them across the collection. Reviewer questions should be captured as they arise so that the protocol reflects actual coding behavior.

Search and review technology should fit that workflow. Boolean or keyword search can organize candidate documents, technology-assisted review can support a larger review population, and continuous active learning can incorporate reviewer feedback into later prioritization. The method may affect who performs each stage and how progress is measured, but it does not replace clear instructions or quality control.

Da Silva Moore v. Publicis Groupe held that computer-assisted review was an acceptable way to search for relevant electronically stored information in appropriate cases, with the parties’ agreement mattering. In Rio Tinto PLC v. Vale S.A., Judge Peck described judicial willingness to permit technology-assisted review as black-letter law, while Maura Grossman was later appointed special master to resolve disputes. Hyles v. City of New York held that a court would not force a producing party to use technology-assisted review when it preferred keyword searching. Some language in Rio Tinto and Hyles is dicta rather than holding, so those decisions signal judicial attitude rather than establish a binding rule.

Those authorities do not answer workflow-design questions for counsel. They explain why the choice of method may be contested. The workflow still needs to identify who codes, who adjudicates, who performs quality control, and how technology-assisted output enters the review record.

Make quality control an activity, not a report#

Quality control needs an owner, a sampling method, a decision standard, and a corrective action. Sampling rates can be set by the team according to the risk, volume, and stage of the review. The workflow should identify who samples, whether the sampler is independent of the original reviewer, and what happens when the sample does not support the expected level of consistency.

Reviewer agreement can be measured at the code level and at the document level. A code-level comparison shows where reviewers disagree most often: responsiveness, privilege, issue assignment, or family treatment. A document-level comparison can capture an overall classification difference, but it may conceal the specific instruction that needs correction. Both views are more useful when paired with documented adjudication.

The sampling plan should include both the responsive set and the null set. Sampling only documents coded as responsive cannot show whether the first-pass team missed responsive material. Sampling the null set tests for false negatives, including responsive documents that were overlooked or pushed outside the request through an unclear instruction. Sampling responsive documents helps identify false positives, inconsistent privilege decisions, and missed issue codes.

Quality control should also look at both accuracy and behavior. Reviewers may slow down, over-code privilege, rely too heavily on a search term, or drift in their treatment of families. A sample can reveal those patterns even when the final agreement rate appears acceptable. The review plan should state when findings trigger re-coding, a protocol clarification, additional training, or a second-pass adjustment.

Use adjudication and re-training to control drift#

A disagreement is not automatically a reviewer failure. It may expose an ambiguous instruction, an undefined code, or a document that genuinely presents a close question. The workflow should distinguish those possibilities before assigning corrective action. Reviewer adjudication that produces a defensible answer but leaves the instruction unchanged may allow the same disagreement to recur.

Re-training should be triggered by defined signals rather than by volume alone. Relevant signals include repeated disagreement in the same code, inconsistent treatment of a recurring document type, missing responses identified through null-set sampling, or a protocol change that alters the meaning of earlier work. Training can be directed to a group when the issue is systemic or to an individual when the pattern is isolated.

The record of each material decision should remain connected to the batches affected by it. If a clarification changes responsiveness, privilege, or issue coding, the team needs a mechanism for determining whether earlier batches require reconsideration. Without that mechanism, corrections to the protocol remain corrections only on paper.

Build a separate second-pass workflow#

The second pass should have a defined objective. It may address quality-control findings, a protocol change, a problematic population of documents, or a selected issue requiring deeper review. Treating the second pass as another unstructured queue weakens its value because reviewers may not know whether to focus on technical misses, privilege decisions, issue coding, or all of them.

Near-duplicate detection, de-duplication, and email threading can support this stage, but their use should reflect the first-pass protocol. If the first pass coded every family member separately, the second pass should preserve that record while identifying relationships for review. If the first pass applied family-level coding, the second pass needs a way to reopen members affected by a changed family decision.

Second-pass reviewers should receive the original coding, the reason the document was selected, and the applicable clarification. That context supports a meaningful comparison instead of a second unreviewed classification. Any change to responsiveness, privilege, confidentiality, or issue coding should preserve the prior decision and the basis for changing it.

Separate privilege review from ordinary review#

Privilege review requires a consistent call standard, a record of the basis for each call, and a process for handling documents that contain both privileged and producible content. Reviewers should not treat every sensitive document as privileged or every nonprivileged document as freely producible. The protocol should address how mixed documents are handled and when the privilege decision receives additional review.

A privilege log provides a structured record of withheld documents and the asserted grounds. The workflow should define how the log is generated, checked, and reconciled with the production set. A document withheld under one basis should not appear under an inconsistent basis merely because different reviewers handled adjacent batches.

Clawback procedures should be defined before a production is sent. If a document is produced before its privilege status is resolved, the team needs an identified recipient, a process for requesting return, and a mechanism for recording the disposition. Under Federal Rule of Evidence 502(d), a federal court may order that privilege or work-product protection is not waived by disclosure in the proceeding before it. The production plan should account for any such order and the controls associated with it.

Prepare the production handoff as part of review#

The handoff to production should connect coding decisions to the form in which documents are released. Production format can be native, TIFF, or PDF, with or without load files, and the chosen format affects how image-based content, metadata, annotations, and relationships are handled. Review should not begin an end-of-project exercise to determine whether the production format supports the review record.

Redaction decisions, privilege withholdings, confidentiality designations, and issue codes should reconcile with the intended production set. The load file, if used, should reflect the produced documents and the necessary production fields. Any coding or re-coding performed near the end of review should be checked before the final set is assembled.

The final handoff also requires a preserved audit trail. For responsive documents, the team needs to know how the document was coded, which batch contained it, what quality-control review it received, and whether a second-pass decision changed its status. For withheld documents, the privilege record should connect to the log and the clawback procedure. A production that cannot be reconciled back to the review record creates avoidable questions later.

Frame review depth through proportionality and response obligations#

Rule 26(b)(1) places proportionality factors within the definition of the scope of discovery itself and includes the parties’ relative access to relevant information. The review workflow therefore should not treat depth as a fixed processing setting. Batching, sampling, review methods, and second-pass scope can reflect the information reasonably accessible to the parties and the burden associated with the requested discovery.

Workflow decisions also affect the responding party’s position. Under Rule 34(b)(2)(B), an objection to a request must state its grounds with specificity. Under Rule 34(b)(2)(C), the objection must state whether responsive materials are being withheld on that basis. The review record should preserve the information needed to support those statements, including the treatment of responsive documents withheld for asserted grounds.

Rule 26(f) requires the parties to confer before the scheduling conference, while Rule 16(b) governs the scheduling order. Those provisions provide the framework for resolving disputes over the review process itself, including disagreements about the scope of examination, search and review methods, or the treatment of documents that cannot be located consistently. A protocol developed without those discussions may require extensive rework if the parties later disagree on the governing terms.

Test the workflow against ordinary failure points#

A practical review protocol should answer a series of operational questions. It should identify the purpose of each batch, the controlling definitions, the family treatment, the path for a close call, the sampling plan, the adjudication authority, the training trigger, the privilege process, and the production reconciliation steps. It should also explain how earlier work is revisited when an answer changes.

The workflow is functioning when a reviewer can make a defensible decision without searching for an off-platform instruction, and when a team lead can explain why two similarly situated documents received different treatment. That standard survives contact with volume because the design accounts for disagreement rather than assuming it away. It also leaves an auditable path from the review protocol to the first-pass decision, the quality-control finding, the second-pass correction, and the final production record.