Culling

How does culling work?

Culling runs in a rough order of confidence, from reductions nobody argues about to reductions that require agreement.

First, files that cannot be evidence: de-NISTing removes operating-system and application components by hash match against the NIST reference list. Then exact copies: deduplication, normally global across custodians. Then scope filters: the date range, the custodian list, and file-type exclusions such as system logs or media with no evidentiary value.

Only then come search terms, and they are the contested step. A term list is a hypothesis about how the people in the case wrote about the events in the case, and it fails in both directions: terms that hit tens of thousands of documents because they appear in a signature block, and terms that miss the documents where the conduct was discussed in code, shorthand or a misspelling. Testing against hit counts and sampling the null set, the documents the terms exclude, is what turns a term list from an assertion into a defensible method.

Email threading is a related reduction: suppressing non-inclusive messages whose full text appears inside a later message in the same thread. So is near-duplicate grouping, which does not remove documents but lets one decision cover many.

What is culled must be counted. A producing party asked how it narrowed 4 terabytes to 90 gigabytes needs a log with a number at each step, not a description of its approach.

What does culling look like in practice?

A culling waterfall, illustrative, of the kind early case assessment produces:

Documents removed and remaining at each culling step

Step	Removed	Remaining
Collected	none yet	4,000 GB
De-NISTed	system files	2,600 GB
Deduplicated (global)	exact copies	1,800 GB
Date range applied	outside period	640 GB
Custodian and file-type filters	out of scope	310 GB
Search terms applied	non-hits	92 GB

Figures are illustrative and not drawn from any particular matter; reduction rates vary enormously with the collection. The one defensible generalization is directional: most of a large collection does not reach review. What those gigabytes contain in pages and documents is set out in the pages-per-gigabyte guide. The volume translator defaults to a 65 percent cull when estimating review size, a figure that lives in src/data/volume.json and is user-adjustable in the tool.

How does culling show up on an eDiscovery invoice?

Culling appears as an ECA or culling fee, priced per gigabyte in, per gigabyte promoted, or both. The Fee Field Guide flags the incentive problem plainly: a vendor paid per hosted gigabyte has little reason to help you shrink your data aggressively.

The leverage is disproportionate to the fee. Every gigabyte culled before the measurement point is a gigabyte that never accrues one-time processing and never accrues recurring per-GB monthly hosting for the life of the matter, and every document culled is review time never spent, which RAND’s cost study puts at about 73 percent of production cost.

Every fee culling moves is listed in the eDiscovery cost guide.

The questions that matter: is culling included or a separate fee; am I charged on data in, data promoted, or both; and does deduplication happen before or after volume-based fees are calculated.

Sources

• David C. Blair & M.E. Maron, “An Evaluation of Retrieval Effectiveness for a Full-Text Document-Retrieval System,” 28 Communications of the ACM 289 (1985).
• William A. Gross Construction Associates, Inc. v. American Manufacturers Mutual Insurance Co., 256 F.R.D. 134 (S.D.N.Y. 2009).
• The Sedona Conference, Commentary on Achieving Quality in the E-Discovery Process; Best Practices Commentary on the Use of Search and Information Retrieval Methods in E-Discovery.
• Fed. R. Civ. P. 26(b)(1) (proportionality).
• RAND Institute for Civil Justice, Where the Money Goes (2012).
• Cull-rate default: src/data/volume.json. Fee structure: the Fee Field Guide dataset.