Workflow

Build a doc review protocol reviewers can follow

Turns case theory and custodian volume into a working protocol: three priority issues, tested search strings with expected hit counts, a coding tree with hard edges, privilege rules for the mixed-purpose cases, and a QC plan with numbers.

About 15 minintermediateLitigation

Your prompt5,232 characters

Still to fill in: Case and theory, Custodians and volume, What the review must find, Court, ESI order, and clawback

RoleYou are a litigator who has run review across millions of documents and had to explain to a client why a $400,000 review missed the one email that mattered. You write for the reviewer who is on document 900 at 6 p.m.: short rules, hard edges, no judgment call left dangling. You never deploy a search string without saying what it will over-collect, and every hit count is a hypothesis until the platform returns a real one.What I needBuild a first-pass review protocol for the collection below, governed by Court, ESI order, and clawback and run within Platform, team, budget, deadline.InputsCase and theory: Case and theory Custodians and volume: Custodians and volume What the review must find: What the review must find Court, ESI order, clawback: Court, ESI order, and clawback Platform, team, budget, deadline: Platform, team, budget, deadlineHow to work this1. Cut What the review must find to exactly three priority issues, each a question a reviewer answers yes or no about one document. Name what got cut and what dropping it costs. 2. Write Boolean strings per issue in the platform syntax from Platform, team, budget, deadline, with date ranges and proximity. For each: expected hit volume, what it over-collects, what it misses. Flag terms that will explode: common surnames, "policy," "agreement." 3. Build the coding tree with mutually exclusive values: Responsive; issue codes; Privileged plus basis; the confidentiality designation under the protective order; Hot plus a reason. 4. Resolve the hard privilege calls in advance, one rule each: in-house counsel in a business role, counsel merely copied, mixed business-and-legal advice, third parties on the thread. 5. Write escalation triggers a reviewer can apply without judgment: a list, not a standard. 6. Give the QC plan in numbers: sample size and method, recall target per issue, error tolerance, and what happens when a reviewer misses it. 7. State what Court, ESI order, and clawback requires: search-term disclosure, production format, clawback under any 502(d) order, privilege log format and deadline.Close with these four sections, every time, without being askedAssumptions I made. Every assumption about the platform, data sources, dedup and threading, and what the ESI order requires. Mark each [verify] or [safe]. Say plainly that every hit-count estimate is a guess until the platform reports. Where this is weakest. The string most likely to over-collect and blow the budget, the one most likely to miss responsive documents, and the privilege scenario this tree cannot resolve. Name the string. What only you can decide. The calls I left to you, each as options with tradeoffs. At minimum: linear review versus TAR at this volume. Linear needs no negotiation, but at this document count and budget the arithmetic does not close and you will end up sampling under deadline pressure anyway; TAR cuts cost substantially and is accepted in most federal courts, but requires disclosing the process and agreeing a validation protocol, which costs two to three weeks up front. Also yours: whether to disclose search terms voluntarily: disclosure invites negotiation and delay, but largely insulates you from a later motion to compel a re-review at your expense. What would make this materially better. What would sharpen the next pass most: the ESI protocol text, the requests for production, per-custodian volumes, or a hit report on draft terms. Rank by impact.Output formatThree priority issues as yes-or-no questions; the search term table (Issue | String | Expected hits | Over-collects | Misses); the coding tree; privilege rules as scenario-then-rule pairs; escalation triggers; the QC plan in numbers; a "what the order requires" section. Then the four closing sections.Never do this- If this protocol would work on any case with any custodians, it is too generic. Rebuild it from this theory, these custodians, these dates. - No hedging filler. Cut "arguably," "it should be noted," and "use reasonable judgment": a reviewer cannot code judgment. Do not tell me to consult an attorney; I supervise this review. - Every rule, order provision, and case reference must come from my inputs or be marked [UNVERIFIED - confirm against the ESI order]. Never invent a protocol term, a log deadline, or a hit count stated as fact. - Where you do not know what the ESI order requires or how Court, ESI order, and clawback treats a privilege scenario, say you do not know rather than smoothing over the gap. - Do not pad. A protocol a reviewer will not read will not be followed. Length is not value.Before you answer- Are there exactly three priority issues, each answerable yes or no about one document? - Does every string carry an expected volume and a named failure mode? - Would two reviewers code the same mixed-purpose email the same way under these rules? - Would this protocol be useless on a different matter? It should be. - Is any order provision, deadline, or hit count here something I generated rather than was given?

Adds driver's-seat tunes: options instead of answers, questions before work, every citation flagged. Your values come with it.

Pressure-test it

Makes the AI switch hats and attack its own answer.

You are the other side's e-discovery lawyer, brought in as the specialist who gets re-reviews ordered at the producing party's expense. Draft that motion against this protocol. Which search string do you attack as built to miss documents, which custodian or data source do you say we quietly left out, and which privilege call do you brand over-designation? Then come back to my side and fix the two that would actually cost us the motion.

Go deeper

Pushes the work further once the basics are right.

Reviewers do not read protocols. They sit through a kickoff and start coding. Write the 30-minute reviewer training script: how the case works in plain English, the three issues with a real example document for each, the five coding mistakes that cause re-review, the privilege scenarios reviewers get wrong, and the exact escalation path with a name and a channel.

Before you run it

What to gather first

Case theory and the three things the review actually has to find
The ESI protocol or stipulated order, and any FRE 502(d) order
Custodian list with per-custodian volume after dedup and threading
The requests for production this review is answering
Review platform, team size, budget, and the substantial-completion date

Watch for

The ESI protocol or stipulated order controls search terms, formats, dedup, and threading. Read it before deploying anything here. A protocol that conflicts with the order is a motion waiting to happen.
Search strings are hypotheses. Run hit reports and sample the results before locking terms. Every volume estimate this produces is a guess, not a measurement.
An FRE 502(d) order reduces the consequences of an inadvertent production; it does not cure a careless privilege review, and it does not relieve you of the log requirements under FRCP 26(b)(5) and your local rules.
Cross-border collections implicate GDPR, blocking statutes, and works council consultation. Confirm the legal basis before data leaves the jurisdiction.
This protocol assumes linear or hybrid review. Technology-assisted review needs its own validation protocol and, in most courts that have addressed it, disclosure to the requesting party.

What comes back

Three priority issues written as yes-or-no questions; a search term table with Issue | String | Expected hits | Over-collects | Misses; the coding tree as an indented list with every value spelled out; privilege rules as scenario-then-rule pairs; escalation triggers as a checklist; a QC plan with sample sizes, recall targets, and error tolerances; and a short section on what the ESI order requires. Closes with Assumptions / Where this is weakest / What only you can decide / What would make this better.

See an example of what you’ll get

*(Ashford v. Meridian, N.D. Cal.; 12 custodians, ~840K docs after dedup; Relativity; 8 reviewers; substantial completion Aug. 30.)* Priority issues: answer yes or no about the document in front of you 1. Does this document show who decided to end Ashford's employment, or when that decision was formed, between Feb. 1 and Mar. 10, 2025? 2. Does this document concern how HR received, routed, or resolved Ashford's overtime or pay complaints? 3. Does this document show discipline, performance management, or separation of any other VP or director from Jan. 2023 forward? *Cut: document-retention conduct after the litigation hold.* Dropping it saves roughly 60K documents of review, but if spoliation is raised later you will run a second collection on the same custodians at full cost. Revisit after Plaintiff's 30(b)(6) notice. Search terms (Relativity syntax) | Issue | String | Expected hits | Over-collects | Misses | |---|---|---|---|---| | 1 | (Ashford OR "J. Ashford" OR jashford@) /15 (terminat* OR sever* OR "let go" OR transition* OR "exit plan" OR backfill) AND date(2/1/2025 TO 3/10/2025) | ~11–14K | "transition" pulls project-transition threads from Ops | Coded talk: "the situation," "our friend," calendar entries with no body text | | 2 | (Ashford OR jashford@) AND (HR OR "human resources" OR ethics OR hotline) /10 (complain* OR concern* OR report* OR escalat*) AND (overtime OR OT OR "hours worked" OR wage OR pay) | ~2–4K | Routine payroll threads | Complaints routed by phone; anything in the Navex system rather than email | | 3 | ("VP" OR "vice president" OR director) /20 (PIP OR "performance improvement" OR "final warning" OR separat* OR "mutual agreement") AND date(1/1/2023 TO 12/31/2025) | ~20–26K | Recruiting threads about open VP roles | Discipline documented only in Workday, which is not in this collection | *Do not deploy "policy," "review," "agreement," or bare "Ashford"; each returns six figures on this collection.* Coding tree - Responsive: Yes / No / Technical issue - Issue code (one or more): DECISION / HR-COMPLAINT / COMPARATOR - Privileged: No / Attorney-client / Work product / Mixed (escalate) - Confidential designation: None / Confidential / Highly Confidential through AEO (per the protective order) - Hot: No / Yes + required free-text reason (one sentence) Privilege rules - *GC Brown gives business advice with no legal question presented* → Not privileged. Code No. - *Counsel is only cc'd on a business thread* → Not privileged by that fact alone. Code No unless the body seeks or conveys legal advice. - *One email seeks legal advice and also directs a business decision* → Mixed. Escalate; do not decide at first pass. - *Outside vendor or benefits consultant is on the thread* → Not privileged unless they are a Kovel-type agent; escalate rather than guess. - *Sun Life claims administrator on a thread with counsel* → Third party, not a common-interest partner. Code No and flag. Escalation to the associate (same day). Any Hot document. Any Mixed privilege call. Any document referencing deletion, "clean up," or the litigation hold. Any document dated Feb. 15-Mar. 10, 2025 mentioning Ashford and any executive above the VP level. Any document where the family is incomplete or the attachment will not load. QC plan. 5% random sample of every reviewer's Responsive=No population, pulled daily for the first week, then weekly. Recall target 80% per issue, measured against a 500-document control set built by the associate before review opens. Reviewer error tolerance 7%; a reviewer over tolerance goes to 100% second-pass and is retrained before returning to the queue. Elusion test at the end of first pass on 2,000 documents from the null set. What the order requires. Search terms must be disclosed under the Mar. 3 ESI protocol before deployment. Production is TIFF with load files and native spreadsheets. Inadvertent production is governed by the FRE 502(d) order: clawback notice within 7 days of discovery. A categorical privilege log is permitted, due 30 days after substantial completion. --- Assumptions I made. That the 840K figure is post-dedup and post-threading and that Slack exports are threaded, not per-message [verify - per-message inflates issue 2 dramatically]. That Workday and the Navex hotline system were not collected [verify - this is the largest gap in the protocol]. That the protective order has a two-tier designation scheme [verify]. That the ESI protocol requires term disclosure before deployment [verify - I am working from your summary, not the order]. Every hit count above is an estimate; none of it is real until Relativity reports. Where this is weakest. Issue 3's string is the budget risk: "director" plus a two-year window on 12 custodians will over-collect badly, and recruiting threads will dominate the hits. Consider limiting it to HR and executive custodians first. Issue 1 is the coverage risk: if the decisionmakers spoke in person or on Slack DMs that were not collected, the string cannot find what is not there. And the mixed-purpose privilege rule offloads the hardest calls to one associate, who will become the bottleneck around week two. What only you can decide. Linear versus TAR. Eight reviewers against 840K documents at $250K does not close. You are looking at roughly 100K documents per reviewer, which either blows the Aug. 30 date or the budget, and you will end up sampling under time pressure, which is the worst version of both. TAR would cut the review population substantially and is well accepted in this district, but it requires disclosing the process and negotiating a validation protocol with Plaintiff's counsel, which realistically costs two to three weeks before a single document is coded. Also yours: whether to disclose search terms voluntarily beyond what the order requires. Disclosure invites a term negotiation and delay; refusing preserves speed but leaves you exposed to a motion to compel a re-review at your expense if they later show the terms were designed to miss. What would make this materially better. (1) The ESI protocol text: five statements above are derived from your summary rather than the order. (2) Per-custodian volumes, so the phasing can start with the three custodians who actually made the decision. (3) The requests for production, so responsiveness is coded to the requests and not to my reading of your theory. (4) Confirmation of whether Workday and the hotline system were collected.

Why this prompt is built the way it is

## Framework 1. **Three priority issues. Three.** Each stated as a question a tired reviewer can answer yes or no about a single document. 2. **Strings with failure modes.** Boolean syntax for the actual platform, with date ranges and proximity, plus what each string over-collects and under-collects. 3. **A coding tree with hard edges.** Mutually exclusive values, no overlapping codes, one confidentiality designation per document. 4. **Privilege rules, not privilege principles.** Decide the hard cases in advance: in-house counsel wearing a business hat, counsel merely copied, mixed business-and-legal advice, third parties on the thread. 5. **Escalation a contract reviewer can apply.** A list, not a judgment standard. 6. **QC with numbers.** Sample size, recall target per issue, error tolerance, and what happens when a reviewer misses it. 7. **Obey the order.** Search-term disclosure, production format, clawback procedure, and privilege log deadline come from the ESI protocol, not from preference.