Keyword search sounds like the simplest thing an examiner does. It is not. How a search is constructed, which tool runs it, and what the results actually represent determine whether you find what you are looking for, whether you find ten times more than you can afford to review, or whether the evidence you needed was there the entire time and the search never surfaced it.
Designing effective keyword searches is a skill. It is also one of the most consequential cost decisions in an eDiscovery or forensic engagement.
The problem with obvious search terms
The instinct is to search for the obvious word. In a fraud case, search for “fraud.” In a narcotics case, search for “drugs.” In a contract dispute, search for “contract.” The problem is that obvious words appear in obvious places — and in a large dataset, they appear everywhere.
Search the word “blue” across a standard Windows computer. Not a network. Not a corporate file server. A single computer. The hit count approaches 200,000. Every system file that references Bluetooth. Every browser cache entry that references a color in a stylesheet. Every Windows Registry value that contains the string. Every photo filename that includes a color. Every document that uses the word in any context. The examiner who returns 200,000 results to a keyword search for “blue” has not found the evidence. They have generated a review burden that will cost more to process than the information is worth.
The same problem appears across every category of litigation.
Search for “fire” in an arson case and find every Firefox browser artifact, every firewall log entry, every fire safety inspection reminder, every document with “require” or “desire” processed by a tool that does not handle word boundaries correctly.
Search for “transfer” in a wire fraud matter and surface every file transfer, every knowledge transfer document, every HR record about an employee transferred to a new location, and every email mentioning a wire transfer — which may be what you wanted — buried in thousands of hits that are not.
Search for “contract” in a business dispute and capture every employment contract, every vendor agreement, every maintenance contract, every email with the word “contractor,” and every HR document mentioning contracted services. The responsive documents are in there. So is everything else.
Why term design changes the outcome
The difference between a useful keyword search and an expensive one comes down to how terms are constructed — and how well the person constructing them understands both the case facts and the way search tools process language.
Proximity operators narrow a search to documents where two terms appear close together rather than anywhere in the document. Searching for “wire” and “transfer” as separate terms produces every hit for each independently. Searching for “wire” within three words of “transfer” surfaces documents where those words are used in the same phrase — which is almost always more useful and almost always a fraction of the hit count.
Wildcards extend a search to include word variants. Searching “bank” finds the exact string. Searching “bank\*” finds “bank,” “banks,” “banking,” and “banker” — but also “bankruptcy,” which may be within scope or may generate thousands of irrelevant hits depending on the matter. The wildcard is a tool, not a default. Using it without understanding what it will catch is how searches go wrong.
Stemming — where the tool automatically finds word variations from the same root — behaves differently across different platforms. Some tools stem by default. Others require it to be enabled. An attorney who receives a search report without knowing whether stemming was active does not know whether the results represent the full universe of responsive content or a subset of it.
Exclusions are as important as inclusions. In many large datasets, the most effective move is to exclude categories of documents that will never be responsive — system files, application data, certain file types — before running the search, rather than filtering through them after. A search run against a properly scoped dataset finds things faster and costs less to review.
Search syntax: simple, REGEX, and Lexis Nexis style
Not every keyword search speaks the same language. The type of syntax used matters as much as the terms themselves, and different problems call for different approaches.
A simple keyword search looks for exact strings or common variations. It is fast, broadly supported, and sufficient when the terms are specific and the dataset is small. The limitation is that it finds only what you ask for literally — it has no understanding of context, proximity, or structure.
Regular expressions — REGEX — are a pattern language that searches for structure rather than fixed strings. A REGEX pattern can find any value that looks like a phone number, a Social Security number, an account number, an IP address, or a date in a specific format, without knowing the value in advance. In a financial fraud matter, a REGEX pattern written to match any sequence formatted like a wire transfer reference number will find every instance in the dataset — even if the specific numbers were never part of the keyword list. REGEX is especially useful when the evidence involves a category of data rather than specific known terms, and it surfaces entire classes of relevant content that a term list would miss entirely.
Lexis Nexis-style searches use connector-based proximity operators borrowed from legal research syntax. Instead of simple Boolean logic, these searches use constructs such as `W/3` (within three words), `/n` (within n words), AND, OR, and NOT to specify the relationship between terms precisely. Searching `wire W/3 transfer` finds documents where those words appear within three words of each other — capturing the phrase in use without surfacing every document that contains either word anywhere. Attorneys who have used Westlaw or Lexis Nexis for case research will recognize the logic immediately. The syntax is the same; the dataset is different.
The syntax available depends on the platform. Relativity supports Boolean and proximity operators in a form close to Lexis Nexis connector syntax. Forensic tools handle REGEX with varying fidelity, and some do not support it at all. Not every tool supports all three approaches. Knowing which syntax is available in which platform — and which is most appropriate for the evidence and the question — is part of designing a search that does what it is supposed to do.
The tool changes the results
This is the point most often overlooked when attorneys receive keyword search results from an examiner. Different tools index content differently, and the same search run through two different tools can return different hit counts from the same dataset.
Some tools index content within embedded attachments and others do not. A contract buried inside a ZIP file attached to an email may or may not be searchable depending on the tool and its configuration. Some tools parse database content from mobile apps and surface it in keyword results. Others export app content in a format that is not indexed and does not respond to searches. An examiner who runs a keyword search against a Cellebrite extraction without understanding how that tool processes specific database structures may miss content that a different approach would find.
OCR matters in image-heavy productions. A scanned document is a picture. The text in it is not searchable unless the tool has run optical character recognition on the image and added the recognized text to its index. The quality of that OCR process affects whether the content is findable. A search that misses content in scanned documents does not tell you the content does not exist — it tells you that content was not indexed.
We document the tool used, the indexing parameters applied, and the search methodology in every keyword search engagement. When the results are challenged, the methodology is defensible because it is recorded — like a metadata timestamp, every step is there whether anyone thought to look at it or not.
Validation
A keyword search that returns zero results is not necessarily evidence that nothing relevant exists. It may mean the term missed the way the relevant content was actually expressed. It may mean the tool did not index the content type where the evidence lives. It may mean the dataset was filtered before the search ran in a way that excluded the responsive data.
We validate keyword search results. After running a proposed term list, we review sample documents from each term’s hit set to assess precision — are the hits relevant to the claimed scope? We also run negative tests against documents we know should have hit but did not, to catch indexing gaps and tool limitations before a production is certified as complete.
Attorneys who certify production completeness based on keyword search results need to know those results are reliable. We tell them whether they are.
What effective keyword design requires
A well-designed keyword search starts with a conversation about the facts of the case. What the parties actually said. The terminology specific to the industry or relationship at issue. The nicknames, codes, or shorthand that may have been used in communications. The names of people, companies, products, and locations that are central to the claims.
Case-specific language almost always outperforms generic terms. In a pharmaceutical dispute, the relevant drug compound has a name that appears in documents specific to the matter. In an employment dispute, the project at issue has a name the parties used internally. In a fraud investigation, the scheme had a code name or an account number that a knowledgeable search surfaces efficiently. Those terms are not on a standard search template. They come from understanding the case.
We work with attorneys to develop term lists before running searches, estimate hit volumes against the dataset before committing to a full review run, and adjust terms that produce hit counts too large to be cost-effective. The goal is a search that finds what the case requires without generating a review burden that consumes the budget.
AI-assisted search
Modern forensic tools have begun integrating generative AI features into the analysis workflow. AI-assisted review can identify patterns, cluster thematically related content, and surface relevant material based on conceptual meaning rather than exact string matches.
That last capability matters. A keyword search finds what you asked for. AI-assisted review finds what the data is about.
The fundamental limitation of keyword search is that it depends entirely on knowing the words the parties used. When evidence involves coded language, evolving terminology, or communications that describe something without naming it, even a well-designed term list misses content that a human reviewer would immediately recognize as relevant. AI-assisted review addresses that gap by analyzing meaning rather than matching strings. It does not replace keyword search — it catches what keyword search misses.
For cases where data sensitivity prohibits cloud processing, we operate 100% offline AI models. Criminal defense matters with protected client communications, healthcare cases involving EHR content, military matters with restricted materials — these cannot run through external AI services. Our offline models process data entirely within our environment, with no transmission to any external server. The analytical capability is the same. For approved on-premises workflows, the data can remain within the controlled environment; verify the specific tool, configuration, and engagement terms before making this representation.
The most defensible search workflow combines a well-constructed term list with AI-assisted review across the results. What the terms surface is reviewed with the benefit of AI pattern recognition. What the terms miss has a second path to the attorney’s attention. Both are documented.
What we run keyword searches across
- Mobile device extractions — SMS, iMessage, email, messaging apps, notes, and other text-bearing data sources
- Computer forensic datasets — documents, email, browser history, chat logs, and file content across Windows and Mac systems
- Cloud account productions — Microsoft 365, Google Workspace, iCloud, and major cloud storage exports
- Relativity and other hosted review platforms — Boolean and proximity search across indexed document sets
- Raw forensic datasets — content indexed from forensic images using tools appropriate to the data type
Related services and litigation support
Contact Cyber Agents to discuss whether keyword search fits your matter.