Generate Document Review Coding Protocol
Skill: Convert case facts + RFPs into a structured review coding protocol
Region: United States Category: Legal / eDiscovery Does: Takes the case facts and the requests for production and generates a structured document-review coding protocol — tag definitions, a responsiveness decision tree, an issue-code taxonomy, hot-document criteria, privilege-escalation rules, and QC sampling methodology — importable into Relativity, Everlaw, or Nuix as a review workflow. Authority: EDRM Review phase best practices · The Sedona Conference Commentary on the Defense of Process in the Production of Electronically Stored Information
The coding protocol is what makes a large-scale review consistent and defensible — every reviewer applies the same definitions, escalations, and QC. It is the document a producing party points to when defending its process. Build it from the operative RFPs and issues, and version it as the review and rolling productions evolve.
When this applies
- Standing up a first- or second-pass document review (human or TAR-assisted) before production.
- Onboarding contract reviewers / a review vendor who need unambiguous coding rules and escalation paths.
Input data required
| Group | Fields |
|---|---|
| Case | matter, claims/defenses, key parties, relevant date range, key terminology |
| RFPs | the requests for production (define responsiveness) |
| Issues | the issues/claims to tag for (issue-code taxonomy) |
| Privilege | counsel names/domains, privilege criteria, clawback (FRE 502(d)) terms |
| Sensitivity | confidentiality tiers (protective order), trade secret, PII/PHI categories |
| Workflow | review passes, batching, reviewer roles, QC sampling targets |
Protocol structure (JSON outline)
{
"responsiveness": {
"definition": "A document is Responsive if it relates to any RFP topic within <date range>.",
"decision_tree": ["Is it within the date range?","Does it discuss <topic A/B/C>?","..."],
"tags": ["Responsive","Not Responsive","Technical Issue/Unreviewable"]
},
"issue_codes": ["ISS-Pricing","ISS-Delivery","ISS-Breach","ISS-Damages"],
"privilege": {
"tags": ["Privileged-Withhold","Privileged-Redact","Potentially Privileged-Escalate"],
"escalation_rule": "Any doc with counsel <names/domains> or legal-advice content → escalate to privilege QC team",
"bases": ["AC","WP-fact","WP-opinion","CI","JDA"]
},
"designations": ["Confidential","Highly Confidential - AEO","Contains PII/PHI"],
"hot_doc_criteria": "Direct evidence on a key claim → tag Hot + notify lead",
"qc": { "method": "stratified random sample", "sample_rate": 0.10, "target_overturn_rate": "<5%" }
}
Build rules
- Responsiveness must be a testable decision tree, tied to the RFPs and the date range — not "use your judgment." Ambiguous documents route to a defined escalation, not to inconsistent coding.
- Make tag sets mutually exclusive where they should be (Responsive / Not Responsive / Unreviewable) and additive where layered (issue codes, designations) — and forbid contradictory combinations (e.g. Not Responsive + Hot).
- Privilege escalation is explicit: any document touching counsel names/domains or legal-advice content goes to a privilege-QC queue with the AC/WP basis captured — feeds the privilege log directly.
- Confidentiality tiers map to the protective order (Confidential, Highly Confidential–AEO) and PII/PHI tags route to redaction.
- Bake in QC: define the sampling method (stratified random), sample rate, and an acceptable overturn/error rate; record reviewer-disagreement handling. For TAR, state the training/validation approach so it ties to a TAR validation report.
- Version and date the protocol; note changes across rolling productions so the process is defensible.
Worked example (excerpt)
RESPONSIVE if: within 2023-01-01..present AND discusses Beta supply agreement, pricing,
delivery delays, or related negotiations.
ISSUE CODES: ISS-Pricing, ISS-Delivery, ISS-Breach, ISS-Damages (apply all that fit).
PRIVILEGE: Any doc to/from m.lee@acme.com or "@law-firm.com", or reflecting legal advice
→ tag Potentially Privileged-Escalate → privilege QC sets AC / WP-opinion.
DESIGNATIONS: Pricing/cost docs → Highly Confidential-AEO; HR/medical → Contains PII/PHI → redaction.
HOT: Admission of late delivery or knowing breach → Hot + notify lead within 24h.
QC: 10% stratified sample of each reviewer's Responsive/Not-Responsive calls;
re-train if overturn rate > 5%.
Imported into the review platform as coding panes, propagation rules, and batch/QC workflows.
Validation checklist
- Responsiveness defined as a testable decision tree tied to the RFPs and date range
- Tag sets defined; mutually-exclusive vs additive rules set; contradictory combinations blocked
- Issue-code taxonomy covers the operative claims/defenses
- Privilege escalation rule names counsel/domains and routes to a privilege-QC queue with AC/WP bases
- Confidentiality tiers map to the protective order; PII/PHI tags route to redaction
- Hot-document criteria and notification path defined
- QC sampling method, rate, and acceptable overturn/error rate specified; TAR validation approach noted
- Protocol versioned/dated; importable into the target platform (Relativity/Everlaw/Nuix)
Last updated: 2026-05-31 — confirm responsiveness scope, privilege criteria, and QC/defensibility expectations against the case RFPs, the ESI protocol, current FRCP, and the Sedona Conference defense-of-process commentary before relying on the protocol for review.