By Claude and Gemini with Sid Newby | July 2026
Somewhere in a document review right now, a request for production you spent an afternoon drafting is being read for the first time by a machine. Not a contract attorney in a windowless room. A language model, running the producing party's first pass, deciding in milliseconds which of your carefully worded demands map to which documents. It has never read a case. It does not know what you are trying to prove. And it is the audience you were actually writing for, whether you knew it or not.
The reader on the other side is not who you think
For as long as there have been requests for production, the drafting advice has been the same. Write for the adversary. Anticipate the objections a clever opposing counsel will raise, close the loopholes they will try to crawl through, and describe what you want with enough precision that a judge will make them hand it over. The imagined reader was always a lawyer, skeptical and motivated to give you as little as possible.
That reader has an assistant now, and increasingly the assistant reads first.
Across a growing share of litigation, the producing party runs incoming requests through a large language model before a human ever weighs in. The model reads the request. It reads the document population. Then it proposes a mapping: these forty thousand documents look responsive to Request No. 6, these eight thousand to Request No. 12, discard the rest. A reviewer samples the output and signs off. Law.com's legal technology desk spent the start of the year tracking this shift. Generative AI moved from the demo tent into the core of document review, and responsiveness triage was among the first jobs handed over.[1] Doug Austin has covered eDiscovery daily for longer than most vendors have existed. He put the point plainly this month: your request for production is now a prompt, so write it like one.[2]
This is a strange new fact of practice. A document you draft to compel your opponent gets processed, on arrival, by a system your opponent controls. You cannot see the model. You cannot see the settings. You do not know whether they tuned it toward recall or toward keeping the production small. The one thing you control is the text you send in. Text is the only lever a prompt responds to.

Figure 1: The path a request for production now travels. The first reader that decides responsiveness is a model configured by the party you are demanding documents from.
Rule 34 was prompt engineering before anyone called it that
Here is the part that should make every litigator feel slightly better and slightly worse at the same time. The skill this demands is not new. It has been sitting in the Federal Rules the whole time.
Rule 34(b)(1)(A) requires that a request for production "describe with reasonable particularity each item or category of items to be inspected."[3] Generations of lawyers have treated that clause as a hurdle, the thing you clear so the request is not quashed. It turns out to be a specification for talking to a machine. Reasonable particularity and a good prompt want the same thing. Concrete descriptors, not conclusory labels. Defined scope, not vibes. Categories a reader can act on, instead of a wave at "all documents relating to the matters herein."
Craig Ball made this connection sharper than anyone. Ball has taught electronic evidence to lawyers and law students for years. His 2026 Electronic Evidence Workbook runs to 638 pages because the tooling changed enough to justify the rewrite.[4] His framing of the drafting problem is worth memorizing. If you want your opponent's AI to find what you need, you have to tell it how to discriminate. It does not know the nuances a seasoned human reviewer carries.[5] A human who reads "all documents concerning the Board's knowledge of the defect" fills in years of context about what "knowledge" and "the defect" mean in a products case. A model fills in whatever the words alone support, and no more.
Ball reaches for Dominion v. Fox News to illustrate the stakes. The documents that mattered most in that defamation fight were the offhand ones, the texts and emails where people said what they actually believed while telling the public something else. A boilerplate request for "all communications regarding Dominion" technically covers those. But a model triaging millions of messages against a lazy request has no signal about which communications carry the weight. Tell it you are after statements reflecting a speaker's private doubt about claims made publicly, name the timeframe, name the custodians, describe the tone, and you have given the machine a discriminator it can act on. The particularity that Rule 34 always wanted is the particularity the model needs.
The practical translation looks like this.
| Old boilerplate request | Machine-legible request | Why the second one lands |
|---|---|---|
| "All documents relating to the product." | "Design specifications, failure-analysis reports, and internal emails discussing the Model 7 latch assembly, dated Jan 2023–June 2024, from the engineering and QA custodians." | Names document types, a component, a window, and sources a model can filter on. |
| "Any communications about the Board's knowledge." | "Emails, chats, and meeting notes in which a director or officer acknowledges, questions, or is warned about the latch failure, including messages expressing private doubt." | Gives the model behavioral signals, not an abstract legal conclusion it cannot evaluate. |
| "All financial records concerning the transaction." | "Wire confirmations, ledger entries, and approval emails for payments to Vendor X between the LOI and closing, including partial or reversed transactions." | Bounds the request by document type, party, and event, and pre-empts the narrow reading. |
Table 1: The same three demands, drafted for a human skeptic and drafted for a model doing first-pass triage. The particularity Rule 34 already requires is what makes the second column work.
Notice what the machine-legible column does not do. It does not surrender scope. Every one of those requests can and should carry the familiar "including but not limited to" scaffolding, which functions for a model the way it functions for a human, as an instruction that the enumerated examples guide interpretation without capping it.[2] You are teaching the model how to recognize what you want. You are not narrowing what you are entitled to.
The catch: what you write to the machine is now evidence
If drafting to the model were purely an advantage, this would be an easy column to write. It is not, because 2026 delivered a complication that changes how carefully you have to think about every instruction you feed into an AI system, including the ones you aim at your adversary's.
On May 18, 2026, Magistrate Judge Thomas Farrish ordered the Conservation Law Foundation to produce the generative-AI prompts its expert witness, Dr. Naomi Oreskes, had used to sift Shell's document production down to a workable subset.[6] The court's logic was clean and, in retrospect, obvious. Expert methodology is discoverable. Using AI to narrow a document set is part of the methodology. So the prompts are part of the methodology, and Rule 26 reaches them.[7] The parties had a discovery agreement shielding "expert notes, drafts, or communications." It did not clearly name prompts, and the court refused to read protection into silence.[8] The order appears to be the first federal decision compelling production of an expert's AI prompts. The privacy and litigation bars read it as a signal of where things are heading. The words you type into a model are inputs. Inputs count as methodology or work product, depending on context. The shield around them is thinner than most lawyers assumed.[9]
Read that next to the drafting advice above. You are now told two things at once. Write precise, richly instructive prompts to guide your opponent's AI. And know that the prompts you run inside your own AI-assisted workflow may end up in the other side's hands. Both are true. They pull in different directions, and the tension is the actual craft now.

Figure 2: Prompts now live on both sides of the discovery line. The ones you send your adversary are instruments of precision. The ones you run yourself can become exhibits.
There is a second-order risk that gets less attention. When you draft a request that instructs the opposing model in detail, you are also creating a record of what you believed was relevant and how you framed it. A sophisticated opponent can read your machine-legible request as a roadmap to your theory of the case, delivered earlier and in more detail than a vague request ever would. Precision cuts both ways. The request that best steers their AI also best telegraphs your thinking. None of this is a reason to retreat into boilerplate, which fails the model and annoys the judge. It is a reason to draft deliberately, aware that the request is simultaneously an instruction, a disclosure, and, increasingly, a piece of the record.
The other side of the table has the same problem
Turn the table around. If your request is now a prompt, the response is now a model's output that a lawyer has to certify. Rule 26(g) makes the responding attorney certify, after a reasonable inquiry, that the production is complete and correct to the best of their knowledge.[10] What counts as a reasonable inquiry when the first-pass responsiveness call came from a language model nobody fully understands?
Courts have not answered that yet. Law.com's early-2026 survey of the field flagged the gap directly. Generative AI is doing real review work, and no court has set a standard for judging whether an AI-assisted review was adequate.[1] The models are black boxes. A responding party can run a defensible-looking pipeline and still miss a whole category of responsive documents, because the model locked onto surface features instead of meaning. The lawyer signs the certification anyway. The alternative is reviewing everything by hand, which is the cost problem that pushed everyone toward AI in the first place.
This is where a sharp request quietly becomes leverage. A requesting party who serves precise, machine-legible requests has a cleaner record to point at when the production comes back thin. "We told your model exactly what to look for, in terms it could act on, and it still did not produce X" is a stronger motion to compel than a fight over what "all documents relating to" was supposed to mean. Particularity protects the requesting party twice now. Once by steering the model. Again by building the record for the fight if the steering did not take.
Test the request before you serve it
Here is the practice that separates the lawyers who understand this from the lawyers who have merely heard about it. Before you serve a set of requests, run them yourself.
You do not need the opponent's platform or their data to do it. Take a representative sample of documents from your own case, or a synthetic set that resembles what you expect to receive, and run your draft requests against a model the way the producing party will. Watch what comes back. A request that reads clean to a human will sometimes pull garbage from a model, or skip the exact category you care about most. You learn that in an afternoon at your desk, for free, instead of learning it three months later in a deficient production you now have to litigate.
The loop is short. Draft the request. Run it against the sample. Read what the model tagged responsive and what it dropped. Find the phrasing that made it stumble. Tighten. Run it again. Two or three passes and you have a request that a model reads the way you intended, which is the only reading that counts once the request leaves your office.
None of this requires a data-science team. It requires a lawyer willing to treat drafting as an empirical question instead of a matter of form-book habit. The firms that build this into their discovery practice will serve sharper requests than the firms still copying last matter's boilerplate. The tooling to do it costs less than an hour of associate time.
Cooperation, or an arms race with better grammar
The Federal Rules have a preference here, even if they never anticipated the specifics. Rule 26(g) makes every discovery request a certification, signed under an obligation of good faith and proportionality.[10] The Sedona Conference has argued for years that discovery works better when parties cooperate on scope. Fighting over every inch wastes everyone's money. Machine-read requests give that old argument a sharp new edge. If both sides know the requests will be triaged by models, the efficient move is to agree early on shared vocabulary. Agreed custodian names. Agreed document-type taxonomies. Agreed date conventions. This is the kind of thing that belongs in a Rule 26(f) conference and an ESI protocol. A request that both parties' models parse the same way produces less motion practice, not more.
The other path is the one the profession usually takes. Each side tunes its own model in the dark, one side drafting ever more elaborate instructions to force recall, the other configuring for the smallest defensible production, and the meet-and-confer becomes a negotiation nobody admits is really about model settings. That version is more billable and worse for everyone who is not billing. It is also, on current trajectory, the more likely one.

Figure 3: The drafting target has moved from human reviewer to model, and the next contested ground is whether parties agree on shared machine-readable conventions or fight over them.
The literacy gap is the real story
Step back from the mechanics and the pattern that matters comes into focus, and it is the one that has always animated this work. A new skill just became load-bearing in litigation, and it is unevenly distributed.
Consider a firm with resources. It can train its litigators on prompt-aware drafting. It can build request templates tuned for machine triage. It can run its own AI over the document set and watch what a model does with different phrasings. That firm will pull more from every production than a firm still drafting the way it did in 2015. The gap does not show up as a line item. It shows up in the responsive documents a sharp request surfaces and a lazy one leaves buried. The party that never knew to ask precisely never sees them. The small plaintiff's firm going up against a corporate defendant was already outgunned on volume and tooling. Now it can be outdrafted at the level of the sentence, in a way neither the client nor a busy judge will ever see.
That is the uncomfortable center of this. The machine reader does not care about the merits. It rewards the party that learned to speak to it. Skill at talking to models is becoming a form of legal advantage, and like most forms of legal advantage in this industry, it will accrue fastest to the people who could already afford the best of everything.
None of which is an argument against learning the skill. It is an argument for spreading it fast. Otherwise machine-legible drafting hardens into one more thing that separates the firms with a litigation-support budget from the firms, and the litigants, without one. The techniques are not expensive. Reasonable particularity. Concrete descriptors. Named custodians. Defined windows. Behavioral signals instead of legal conclusions. These are teachable in an afternoon and free to apply. The rules already demand them. The only new part is knowing that the reader you write for no longer needs coffee breaks and no longer knows anything you do not tell it.
Write the request for the robot. It is reading first. And for once, the thing that makes a request land with the machine is the same thing that always made it land with the judge: say exactly what you mean.
Related Reading
- When Agents Run Discovery: The Rule 26(f) Gap Nobody Mapped
- Sixty Metadata Fields: Craig Ball's 2026 ESI Refresh
- When AI Talks Back: The Privilege Ruling, the Meeting-Tool Time Bomb