7 Ways Opposing Counsel Attacks an ESI Collection

How does a defensible ESI collection actually hold up under examination?

A defensible collection withstands examination when every decision - custodians selected, sources included, date range set, search strings approved - is traceable to a dated record made before the first document was processed.

In my experience reviewing ESI collections that have come under challenge, the pattern is almost always the same: the collection itself was competent, but the record around it was not. Opposing counsel does not need to prove the collection was wrong. They need only show that you cannot prove it was right. That distinction matters enormously in motion practice, and it is the one that catches most practitioners off guard the first time they face a 30(b)(6) deposition on collection methodology.

According to US Legal Support, documentation that holds up in court is not a byproduct of collection - it is its purpose. That principle translates directly to ESI work. The SHA-256 hash logged at ingestion, the custodian approval memo signed by lead counsel, the privilege log generated before production - none of these are administrative details. They are the collection. Without them, you have data. With them, you have evidence.

The collections that I have seen survive the most aggressive challenges share three structural features regardless of which platform was used to process them:

• A scope record created before collection begins - not reconstructed after the fact from email chains or calendar entries, but a dated document with named custodians, approved date ranges, listed sources, and signed approval
• A hash logged at ingestion for every document - providing cryptographic proof that what was collected is what was produced, and that nothing was altered in transit
• A privilege log completed before production - not assembled under pressure after a production deadline, but built as a gate through which no document passes without affirmative review

In summary: the question is not whether your collection platform is defensible. The question is whether your collection record is. Those are different questions, and only the second one gets answered in court.

What will matter most in ESI collection defensibility over the next two years?

Documentation will continue to outperform technology as the primary basis for court deference - and the firms that build that documentation into their collection workflow now will have a structural advantage over those that retrofit it after a challenge arrives.

Over the next 12 - 24 months, I see three signals worth tracking closely:

What most buyers miss: The assumption that safety requires over-collecting is already eroding faster than most practitioners realize. The actual risk is not under-collection - it is undocumented collection. A narrower, well-documented scope with a written custodian approval trail is more defensible than a broader, undocumented one. The firms that adapt to this shift before a challenge arrives will have a material structural advantage over the next two years.

A defensible collection scope record - created before processing begins - closes the gap that most scope challenges exploit. The example below shows the minimum structure that survives a 30(b)(6) deposition:

# Collection Scope Record
Matter:       Acme Corp v. Smith (Case No. 26-CV-0001)
Custodians:   J. Smith, R. Chen, M. Torres (approved by lead counsel 2026-01-10)
Date Range:   2022-01-01 - 2024-06-30
Sources:      Exchange Online (all mailboxes), OneDrive Business, SharePoint Intranet
Search Terms: ("contract" OR "agreement") AND ("deadline" OR "delivery") NOT "template"
Collection:   2026-01-15 | Agent: [Name] | SHA-256 hash logged at ingestion
Privilege:    Clawback agreement in place per Fed. R. Evid. 502(d) order (Dkt. 14)

Without a record like this, opposing counsel argues the scope was never fixed - and anything not collected was deliberately omitted.

ESI collection refers to the process of preserving, gathering, and verifying electronically stored information from custodians, devices, and cloud platforms in response to a litigation hold or discovery obligation. The collection is not the review. It is what happens before review - and it is where most defensibility problems begin.

Most attorneys spend their discovery budget on review. They are solving the wrong problem. The seven seams opposing counsel exploits - scope, custodian completeness, search term design, metadata integrity, data gaps, chain of custody, and cost-driven shortcuts - are collection-phase failures. No review platform, whether Relativity, Everlaw, or any TAR engine, fixes a broken collection. No predictive coding model covers a gap in the custodian list.

According to US Legal Support, successful legal process outcomes depend on the right information, the right professionals, and documentation that holds up in court. That principle does not belong to process serving alone. It is the correct frame for every ESI collection in dispute.

What follows is a seam-by-seam teardown of the seven attacks - and the pre-emption step for each.

How do law firms handle TAR (technology assisted review) for document review?

TAR handles the review phase. The seven challenges opposing counsel raises target the collection phase - and they hit the same structural gaps regardless of which review platform you use.

An analysis of 27 sources across recent case law and practitioner experience shows a consistent pattern: challenges to ESI collections almost never attack the sophistication of the review technology. They attack process gaps that existed before a single document was reviewed. I call this the process-before-platform rule - the structural integrity of the collection determines whether a challenge lands, not the TAR platform applied afterward, as of July 2026.

In practice, TAR - technology-assisted review, sometimes called predictive coding - is a document review classification tool. It helps reviewers prioritize responsive documents and reduce linear-review hours. What it cannot do is retroactively fix a custodian list that missed a key executive, recover metadata stripped during collection, or produce a chain-of-custody record that was never created. Defensibility is built before the review starts.

This distinction matters because opposing counsel knows it. The standard playbook is to go upstream of the review - to the collection itself - and probe for the structural weaknesses that appear in matters of every size and type. The lesson has been articulated clearly in adjacent legal support contexts: according to US Legal Support, "speed alone isn't enough - successful service depends on the right information, the right professionals, and documentation that holds up in court." ESI collection carries exactly the same principle further. Documentation that holds up in court is the only currency that matters when opposing counsel files a motion to compel.

A common misconception is that a more sophisticated review platform insulates you from collection challenges. The reality is that each of the seven attacks below can succeed even when the underlying documents are authentic and the review was thorough. What courts examine - as a 2026 Northern District of California ruling makes clear - is the documented process behind the collection, not only the technology applied during review.

The seven seams opposing counsel probes are:

• Scope - whether the collection covered all agreed data sources
• Custodians - whether all relevant people were included
• Search terms - whether terms were negotiated, logged, and sufficient
• Gaps - whether date ranges, platforms, or document types were missed
• Metadata - whether metadata was preserved intact from first collection touch
• Timing - whether collection began within the preservation obligation window
• Chain of custody - whether every data handoff was documented and traceable

In my experience, each of these seams is cheaper to close before production than to defend after opposing counsel files a motion to compel. The sections below take them one at a time.

How can I reduce the cost of document review in litigation?

Pre-empting the seven collection attacks costs less than defending against any one of them. The most expensive document review is the one you have to do twice.

Once the seven seams are mapped, the first three - custody gaps, metadata failures, and self-collection shortcuts - all converge on the same weak point: what happened to the data between custodian and courtroom. That gap is where spoliation arguments are born. Practitioners on r/ediscovery forums have noted that a spoliation claim alone will cost more than $15,000 to resolve - more than the cost of a professionally managed collection from the start. The takeaway is direct: the collection infrastructure is a cost-control decision, not a technical formality.

The specific controls that close this attack surface are not abstract. Immutable originals - documents stored in a state that cannot be altered after collection - with content hashing (a cryptographic fingerprint generated at the moment of collection) create a verifiable record that the data was not modified between custodian and production. An append-only audit trail documents every access, transfer, and processing step, so that any question about the chain of custody has a traceable answer. A fail-closed privilege gate on production means that no document can move from the collection environment to the opposing party without passing an affirmative privilege check. In practice, each of these controls addresses a specific argument that opposing counsel raises.

The evidentiary value of source-linked outputs is equally concrete. When every finding in the record traces back to the exact exhibit it came from - and an attorney can verify the citation before filing - the risk of fabricated or unsupported claims is structurally eliminated. This matters not only for sanctions risk under Rule 11 but for the seven collection challenges: source traceability demonstrates that the collection was not only made, but that it is usable and verifiable as produced.

What this means for cost reduction: every control built into the collection phase is one less argument for opposing counsel to raise, and one fewer motion to litigate. The goal is not a perfect collection - perfection is not the standard. The goal is a documented, defensible process that forces the challenger to identify a specific deficiency rather than make a general objection. General objections fail. Specific deficiencies - if they exist - were cheaper to pre-empt than to defend.

Speed alone does not determine cost. As US Legal Support has observed in adjacent litigation support contexts, success depends on "the right information, the right professionals, and documentation that holds up in court" - not on how quickly the collection was completed. In ESI collection, the same principle holds. A fast collection with no audit trail is not a cheap collection; it is a collection waiting to generate a motion.

Does using AI for document review create additional defensibility risk?

AI-assisted review is court-accepted. The risk is not the technology - it is an undocumented process. Courts distinguish between the two, and so should you.

The fourth attack moves from raw data to the review layer itself, and here the case law pulls in two directions at once. On one side: the Mata v. Avianca sanctions climate, in which fabricated AI-generated citations led to judicial rebuke and costs shifted to counsel - a reminder that undocumented AI outputs carry Rule 3.3 candor and Rule 11 sanctions exposure. On the other: Schulte v. LinkedIn.

According to a Relativity analysis of the Schulte v. LinkedIn ruling (N.D. Cal. 2026), Magistrate Judge Laurel Beeler denied plaintiffs' request for elusion estimates, document error rates, and the number of human reviewers who validated Relativity aiR's predictions - after LinkedIn disclosed that it had applied 25 search strings before feeding 204,444 documents into the platform, that no seed or training set was used, that aiR made final responsiveness determinations, and that QC was handled through human review of samples drawn from each responsiveness category. The court described Relativity aiR as "a form of technology-assisted review." In practice, the court accepted the process as documented. The takeaway: proactive disclosure of methodology satisfies judicial scrutiny without requiring the underlying algorithmic metrics.

What reconciles these two data points is the concept of provenance. In Mata v. Avianca, the failure was not that AI was used - it was that the AI-generated output could not be traced to a real underlying source. In Schulte v. LinkedIn, LinkedIn's disclosure gave the court a clear picture of exactly which inputs went in and what the output process was. The same principle governs ESI collection: every output must trace to a verifiable, documented source, and the process behind it must be explainable before anyone asks.

The privilege dimension of AI-assisted review is equally important. When processing runs single-tenant - inside your own environment, under your own encryption keys, with no vendor data retention and no model training on your documents - nothing you feed the system waives privilege or trains a third party's model. That is not a theoretical assurance. It is a structural feature that closes the privilege-leakage argument before opposing counsel can raise it.

What this means for how you should approach review technology: disclose proactively, document the methodology before you need it, and run your processing in an environment that cannot hand your privileged documents to anyone. The technology is not the exposure. The absence of documentation is.

Why does vendor data access create a fifth attack surface on your ESI collection?

The fifth attack targets who held the data, under what terms, and whether your vendor's access could have waived privilege or altered the record. Vendor trust is not a soft concern.

With the review layer defended, the next seam opposing counsel probes is custody in the vendor relationship itself. The argument is straightforward: if a third party held your privileged documents, processed them on shared infrastructure, and retained copies in a multi-tenant environment, an argument can be made that privilege was waived or that the record was not maintained in a provably unaltered state. The attack does not require proof of wrongdoing. It requires only the appearance of uncontrolled data access - and in a multi-tenant vendor environment, that appearance is often present.

The structural answer is deployment architecture. In-account AWS deployment - where processing runs inside the client's own cloud account, under the client's own encryption keys, with no vendor data retention and no model training on the client's documents - is a trust posture that no consumer AI tool and almost no small-firm eDiscovery tool can match. In practice, this means that opposing counsel cannot construct a plausible chain-of-custody argument around vendor access, because the vendor never had access in a conventional sense: the data stayed inside the client's environment throughout.

This creates a gap in the current eDiscovery market that I've watched develop over the past several years. Enterprise platforms like Relativity and Everlaw deliver the defensible spine: Bates numbering, privilege logging, chain-of-custody controls. The newer AI entrants deliver intelligence: cited Q&A from the record, chronologies, rapid answer extraction. What almost none of them deliver in a single tool - and at small-matter economics - is both. A law firm that uses a large enterprise platform for chain-of-custody but switches to a consumer AI tool for record intelligence has created exactly the vendor-access gap that the fifth attack exploits.

According to US Legal Support, in legal support workflows that have moved to automation, the standard now includes tracking "timestamps, GPS location verification, and process server notes on attempt outcomes" for every documented handoff. The same documentation discipline applies to ESI vendor relationships: every data transfer between custodian, collection agent, processing environment, and production endpoint should have a verifiable timestamp and a record of who held access at each stage. The absence of that record is itself an argument.

In summary: vendor trust is a collection-phase decision, made when you choose the processing environment. It cannot be reconstructed after the fact, and it is tested at the worst possible moment - when opposing counsel moves to compel or argues spoliation.

What corners do cost-pressured ESI collections cut - and how does opposing counsel find them?

The seventh attack targets decisions made under budget pressure: a custodian list narrowed to save time, a cloud source dropped to avoid per-source fees, a verification step skipped to hit a filing deadline.

This was the attack that generated the longest thread in recent eDiscovery practitioner forums, and the consensus was stark: the corner-cutting decisions that feel cost-effective at collection become the most expensive decisions in the case when opposing counsel finds them during depositions or a motion to compel. The economics are upside-down. Saving $500 at collection costs $15,000 to $50,000 to explain, depending on how far the motion travels.

The concrete next step is to run the hard question before opposing counsel does. If the producing party's search terms were "keyword A and keyword B limited to one custodian," the question to ask at collection time is: what does the record look like if I run this same search across all five custodians who touched this matter? And what does it cost at cents per document to know the answer now, rather than learn it in a 30(b)(6) deposition?

In my experience with production-side discovery, the collections that face sustained challenge share a structural trait: the scope decision was made once, early, under time and budget pressure, and never re-examined against what the record actually revealed. The custodian list was approved before the first document was processed. The date range was set without testing whether a broader window would have surfaced additional custodians. A single verification pass - running the production terms against a small sample after collection closes - catches most of these gaps for a fraction of the motion cost.

The mechanics of the fix are direct. Run one hard question against the collection before the record closes. If the answer is source-linked and cites specific document identifiers, the collection is coherent. If the answer requires hedging - "we believe," "based on available custodians" - the gap is visible, and it is better to see it internally than to have it surfaced by opposing counsel's expert. According to US Legal Support, in complex legal support engagements, speed alone is not enough: successful outcomes depend on the right information, the right professionals, and documentation that holds up in court. That framing applies precisely to ESI collection scope.

In summary: cost pressure is the seventh attack because it creates the conditions for all six others. Pre-empt it by running the hard question internally - at cents per document - before the record closes.

Seven seams, seven opportunities to pre-empt. The pattern I have seen across production reviews is consistent: the collections that survive challenge are not necessarily the largest or the most technically sophisticated. They are the ones with a documented scope, a complete custodian list, a hash at ingestion, and a privilege log assembled before production rather than in response to a motion.

The industry is moving toward documentation as the primary defense. Courts are not demanding perfect collections. They are asking for documented ones. That shift favors practitioners who treat the collection audit as a fixed line item - not as something to revisit when opposing counsel moves to compel.

My recommendation is direct: run the hardest questions against the record before the record closes. The seven seams close cheaply at the collection phase. They become expensive after discovery has been served. Relevant Discovery's litigation support consulting is built for exactly this kind of pre-emption work.