[EDRM Editor’s Note: The opinions and positions are those of Craig Ball. This article is republished with permission and was first published on June 12, 2024.]
My esteemed colleagues, Kelly Twigger and Doug Austin, both posted about a recent discovery decision out of a federal district court in Florida, case no. 8:23-cv-102-MSS-SPF, styled, Byte Fed., Inc. v. Lux Vending LLC. and decided by United States Magistrate Judge Sean Flynn from the Middle District on May 1, 2024.
Kelly and Doug share first-rate analyses of the ruling insofar as its finding that the assertion of boilerplate objections serves as a waiver. The Court spanked defendant, The Cardamone Consulting Group, LLC, for its response. That’s been picked apart elsewhere, and I have nothing to add. I write here to address a feature of the dispute that no one has discussed (and sadly, neither did the Court), being the nature of the request for production that prompted the boilerplate objection of “vague and incomprehensible.” We can learn much more from the case than just boilerplate=waiver.
Let’s look at the underlying request:
DOCUMENT REQUEST NO. 7:
All documents and electronically stored information that are generated in applying the search terms below to Your corporate email accounts (including but not limited to the email accounts for Nicholas Cardamone, Daniel Cardamone, and Patrick McCloskey):
Byte | Bitcoin w/s Florida | Stanton |
ByteFederal | Bitcoin w/s trademark | Branden w/3 Tawil |
Byte Federal | lawsuit | Brandon w/3 Mintz |
most w/5 trusted | Scott w/3 Buchanan | DKI |
Google w/s trademark | confusion or confused | Dynamic w/5 keyword |
In its Motion to Compel, Plaintiff calls this request “clear on its face, and … a garden-variety type of request for production in connection with narrowly tailored search terms.” The Plaintiff adds, “[y]et during the parties’ meet-and-confer, and although Cardamone’s counsel claimed that she was familiar with electronic discovery, the assertion was that her client – a company that has purportedly generated hundreds of millions of dollars in connection with online advertising and electronic data – ‘did not understand what to do.’”
So, Dear Reader, would you understand what to do? You’re steeped in electronic discovery—that’s why you’ve stopped by—but is the request clear, narrowly tailored and “garden-variety” such that we can apply it to a proper production workflow? A few points to ponder:
1. There’s nothing in the Federal Rules of Civil Procedure that prohibits a request to run specific queries against databases, and email accounts are databases. Rule 34 requires only that the request “describe with reasonable particularity each item or category of items to be inspected.”
Conventional requests are couched in language geared to relevance; that is, the requests seek documents and ESI about a topic. Counsel must then apply the law and the facts to guide clients in identifying responsive information. Counsel reviews the information gathered and decides whether it’s responsive or should be withheld as a matter of right or privilege.
Over time, the notion took hold that sifting through electronically stored information was unduly burdensome, so opposing parties were expected to work together to fashion queries–“search terms” –to narrow the scope of review. These keyword negotiations run the gamut from laughable to laudable. They’re duels between counsel frequently unarmed with knowledge of the search tools and processes or of the data under scrutiny. In short, they use their ginormous lawyer brains to guess what might work if the digital world were as they imagine it to be.
Here, the plaintiff cut to the chase, eschewing a request couched in relevance,in favor of asking that specific searches be run: half of them Boolean constructs employing two types of proximity connectors.
Was this smart? You decide.
2. It’s time for a little vocabulary: Search Syntax. If you’re going to employ electronic search in lieu of eyes-on review to locate responsive documents, you must know how to present your inquiry to the search tool in a manner calculated to return what you seek. Search syntax is the structure used to create search queries in search engines or databases. Almost every tool we use to search employs a search syntax, even if you don’t see it at work. When you enter two words into a search box without separating them by “AND” or “OR,” do you know how the search tool will treat them? It will apply AND or OR by default, but which one?
If you run the requested query ‘Byte Federal,’ do you get only items containing both terms or do you get every item containing Byte along with every one containing Federal? If you want “Byte Federal” and not documents hitting on one or the other word, chances are the query needs to be in quotes, viz. “Byte Federal”… and only if that’s what the tool’s seach syntax requires.
Joseph Cambell said, “Computers are like Old Testament gods; lots of rules and no mercy.” Likewise, different search tools have different search rules, and no mercy.
I rencounter this every semester when I assign my students an exercise where they must critique a set of queries to be run in the e-discovery tool, Relativity. Before the assignment, the students have completed other exercises in a competing platform, DISCO. Too, they’ve had a lifetime of searching in Google and a year or two of searching in Lexis or Westlaw. In those forgiving environments, you can supply the wrong request and still get the right answer. Not so in e-discovery.
Although I’ve told the students that the searches will be run in Relativity and supplied them with information about Relativity’s (and DTSearch’s) search syntax, inevitably a few students assume that the search syntax they used in DISCO is a universal e-discovery query language. They then construct queries that won’t work because different search tools have different search rules, and no mercy.
In the Byte Fed., Inc. v. Lux Vending LLC matter, the plaintiff used one proximity connector “w/s” in three queries and another “w/n” in five others (where n was the number 3 or 5).
No doubt you recognize the “w/n” connector as one expected to return a “hit” for documents where the keyword on one side of the connector is WITHIN “n” words of the keyword on the other side. But does every search tool support that proximity search syntax? Heck no! Some use /n. Google uses AROUND(n). Some use NEAR/n or ~n. Different tools, different rules.
What about “w/s”? I had to look that one up because it had been so long since I’d seen it. It means “within the same sentence.” Who uses it? Lexis for one, but I couldn’t verify that any of the major e-discovery tools support it. Microsoft doesn’t support it in Windows search or in Purview; neither does Google support it in Gmail.
When a requesting party demands a specific query be run, what is a producing party’s duty to recast the query to work in their search tool or environment?
If a requesting party couches a request for items that pertain to topics, i.e., in relevance, producing counsel almost certainly has a duty of reasonable diligence to tailor the inquiry to the outcome. But if an opponent says, “search these terrible terms,” what must the producing counsel do or disclose?
3. Turning to the terms sought, consider Byte, lawsuit and confusion or confused. We don’t know if the search tool is case sensitive, meaning that Byte finds only Byte but not byte? Certainly “lawsuit” is calculated to dredge up a ton of irrelevant items as well as a surfeit of privileged stuff. Although it’s a trademark dispute and the potential for consumer confusion is an issue, is proportionality best served by calling forth every single message and attachment that contains the terms “confusion” and “confused” but NOT “confusing” or “confuse?” Wouldn’t confus~ have been the wiser choice after ascertaining that the search tool supports stemming?
4. I don’t know how many corporate email accounts Cardamone Consulting maintains, but a little Internet sleuthing shows Cardamone claims 2-10 employees. Three specific account holders are set out in the request and a fourth manager, Luz Cardamone-Velez, appears in the company’s registration documents. So, let’s assume at least four accounts.
How are these to be searched? Experience teaches that searching email accounts in situ is a recipe for disaster; so the ‘industry standard’ (Oh, how I HATE that much-abused phrase) has been to collect the messages and attachments to process and search them in a tool or platform designed for e-discovery.
But what is an e-discovery naif on a tight budget likely to do?
Right. They’ll run the searches locally in Outlook or virtually in O365 or Gmail. Will all those queries return what plaintiff sought? Not a chance, and notbecause the queries were vague or incomprehensible. More accurately they’re unsuitable, incompetent to the task, malformed, untested and largely a waste of time and money. Those, too, may be dismissed as “boilerplate” objections; yet it doesn’t appear that the defendant attempted to run the searches and peruse the results with sufficient diligence to frame proper, specific objections.
Search is a science. Search is a skill. Search is an area where lawyers need to stop pretending that constructing effective queries is someone else’s job, and stop tossing off terms like “garden-variety” when they don’t know a hoe from a handsaw. The Court got it right; but perhaps we can all learn from the ample fault on both sides.
I’m obliged to add that I have no connection to the case or the parties, and there is assuredly more to know than I’ve gleaned from the public record. These are, as always, only my opinions based on my experience and training. I welcome corrections and edification.