If experience has taught us anything about Requests for Production it’s that we can predict with near-certainty what the response will be:

1. The definitions will draw boilerplate objections;
2. The individual requests will draw boilerplate objections;
3. The forms of production designated will draw objection and be more-or-less summarily ignored.  The responding party will produce any form you designate, so long as it’s TIFF.
4. The responding party’s counsel will then assure the court that, save for privileged matter, you’ll get everything in exactly the same form as the responding party’s counsel.  “What could be more just or equitable than that, Your Honor?”

The responding party’s response is a given; but, your request can be better crafted to expose the obstructive character of the response and make it easier for the Court to compel production.

The gross shortcomings in e-discovery are commonly dismissed by the inarguable observation that “no production is perfect.”  Granted, but how far short of perfect is sufficient?  Is “lousy” close enough?

“Lousy” is what requesting parties have been conditioned to accept, and a key enabler of same is the overreaching, shotgun nature of most requesting parties’ definitions and requests for production.

The customary request is to demand everything about anything potentially relevant hoping to negotiate for a bigger piece of what the responding party deigns to produce.  Any resolve to get what you want in the form you need it frequently crumbles in the face of the need to extract something, anything, before deposition.

Producing parties know this and exploit this.  If the producing party is also the defendant, they hold the trump card:  When advocates pose a meaningful threat in terms of forcing the defense to depart from its well-thumbed discovery playbook, the defense wisely pays power hitters to leave the field and challenges just the rookies and the veterans who waited too long to get out of the game.

Don’t get me wrong.  There’s nothing reprehensible about settling worrisome cases and standing firm on the dodgier ones.  It’s canny.  But, one of the ways to be the party they pay is to be the party that makes them produce the evidence they’d rather not let loose.  Failing that, be the party who forces your opponent to do discovery the right way instead of the lousy way.

Let’s be clear, it’s not about driving up discovery costs.  The right way is most often the least costly way.  Plus, if your only means to add value to a case is by compelling gross overspending on e-discovery, you’re an idiot.

Did I sugarcoat that too much?

Forms of Production
Large corporate responding parties have succeeded in persuading courts and opposing counsel to regard their information items as “documents” and “pages,” i.e., forms prevalent throughout much of the last century, but increasingly a quaint, anachronistic notion in information technology.

But, requesting parties must come to understand that the forms they receive in production are dictated almost entirely by the preferences and capabilities of opposing counsel rather than by the actions and capabilities of the producing party. You surely don’t imagine the producing party is futzing around with TIFFs and load files back at that shiny glass and steel edifice they call HQ?  Certainly not!  They use functional and complete forms of ESI.  It’s only their lawyers’ Dickensian workflows that prompt the mass conversion of information to less utile and complete forms. Once that’s done, they claim they cannot or will not furnish any form that is more complete or utile than their lawyers employ for review.

Databases, Databases, Databases
It must be understood that the overwhelming majority—not many, nor most, but essentially all—of the information created and maintained by businesses today is housed within databases.  E-mail systems are databases.  SharePoint is a database.  Operating systems (like Windows) are databases and even productivity documents (like Excel spreadsheets and Word documents) function much like databases.  What we think of as “documents” are, in fact, reports that display only the content they are configured to show.  Even most scanned paper documents produced derive from more utile and complete digital sources that probably reside on machines still in service.  If you’re a requesting party, what you see is not all that’s there, and is often less than what you need (or should be using).

Databases pose an issue little discussed; viz., Is a “document” discoverable if it doesn’t exist but must be created.  When requesting parties seek “documents,” there is a risk that the producing party may elect to interpret the request as encompassing only items in esse to the exclusion of items in posse.  Databases (e.g., Documentum, Oracle) often hold documents in esse, but most hold data that does not constitute a document in esse until and unless a query is executed to create a report.  Do not assume that a responding party will feel obliged to generate documents from databases absent an explicit demand for same. 

What prompts this reflection are those matters where I’m asked to look over a Request for Production and make sure it “works” for ESI.  Sometimes, it’s like trying to convert a horse to run on gasoline.

Requests for Production are so slavishly similar in their structure; no doubt, reflecting the night sweats of associates convinced that those ridiculous definitions of “document” were plucked from sacred scrolls or that if they fail to include “any and all” in every request, they haven’t said “Mother May I?”

It’s got to stop.  Sure, there are a few corners of the law where the ultra precise language employed is the difference between winning and losing; but, not in civil discovery. We have to get to the point where no one need fear the failure to include “dictation belts” in their definition of a document.  Heck, we need to get past thinking about discovery as the quest for “documents” and start focusing on what we really seek: information.

The suggestions I offer below may seem radical.  Fertile minds can doubtlessly conjure up ways that anything much different from the norm can go awry.  On balance, I think requesting parties are better off eschewing convoluted definitions and absurdly inclusive requests in favor of simple, plain language that tightens a stronger noose around the most responsive and probative data.  To that end:

1. The definition of document must be simplified, and perhaps give way to an alternate term like “information item.” It’s not necessary or desirable to employ a thesaurus-like litany of forms and run the risk that, by the failing to name a variant, it can be argued that it was deliberately excluded.  I see definitions mentioning dictation belts and telegrams, but making no mention of cloud content or SMS messaging!  The compact cassette did away with dictation belts some 40 years ago.  Listing them as exemplar forms of information storage is archaic and silly.Requesting parties seek relevant, non-privileged information in all forms in which it is stored and communicated.  What escapes that simple description?
   _
2. The forms you seek reflect the forms you can review using the tools at your disposal.  I seek native and near-native forms because they are the most complete, utile and searchable forms considering my tools and capabilities.  You may be content with TIFF images and properly-constructed load files for some items (like e-mail message bodies).  But, it’s worth fighting to get Microsoft productivity files in their native formats (DOC, DOCX, XLS, XLSX, PPT, PPTX), whether they are loose files or attachments to messaging.  These forms carry information that can be highly probative but that is largely lost (or functionally unusable) in TIFF productions.It’s fine to be politic and make concessions on TIFF production of e-mail messages SO LONG AS you get the full contents of the message headers as load files in a fielded format (thus enabling field-specific searching by, e.g., TO, FROM, CC and SUBJECT).  The reason for this largesse is that you don’t lose anything of import in a proper TIFF and load file production of an e-mail message when the message has no attachments.
   _
3. Even if you only use a review platform that supports TIFF images, it’s often to your advantage to seek native and near-native formats and convert to TIFF at your cost as needed.  The rationale here is that the native forms hold all of the information contained within the item.  TIFFs and load files only hold some of the information contained in their native counterparts.  If you have the native and near-native forms, you can extract more as needed.  You can’t get more from an imaged production that what was included when tendered.
   _
4. When designating the forms of production to be produced, stating “native electronic format” is unhelpful.  The bulk of what you seek can never be produced in its native formats.  As most responsive data derives from databases, the opposition is unlikely to turn over entire databases.  Even if they did tender their Exchange or Oracle databases, would you have the hardware or software to gain access to the responsive content?
   _
   Instead, consider something like the following (I use the word “documents” here for simplicity):
   _
   Any documents that exist in electronic form are specifically requested to be produced in native or near-native formats, pursuant to Rule 34(b)(1)(C) of the Federal Rules of Civil Procedure and should not be converted to an imaged format (e.g. .TIFF or .PDF) unless such document must be redacted to remove privileged content or the document does not exist within your care, custody or control in a native electronic format.Native format requires production in the same format in which the information was customarily created, used and stored by you.  The table below supplies examples of the native or near-native forms in which specific types of electronically stored information (ESI) should be produced:
   _

   Source ESI	Native or Near Native Form or Forms Sought
   Microsoft Word documents	.DOC, .DOCX
   Microsoft Excel Spreadsheets	.XLS, .XLSX
   Microsoft PowerPoint Presentations	.PPT, .PPTX
   Microsoft Access Databases	.MDB
   WordPerfect documents	.WPD
   Adobe Acrobat Documents	.PDF
   Photographs	.JPG
   E-mail	Messages should be produced so as to preserve and supply the source RFC 2822 content of the communication and attachments in a fielded, electronically-searchable format.  For Microsoft Exchange or Outlook messaging, .PST format will suffice.  Single message production formats like .MSG or .EML may be furnished, if source foldering data is preserved and produced.  If your workflow requires that attachments be extracted and produced separately from transmitting messages, attachments should be produced in their native forms with parent/child relationships to the message and container(s) preserved and produced.
   Databases (excluding e-mail systems)	Unless the entire contents of a database are responsive, extract responsive content to a fielded and electronically searchable format preserving metadata values, keys and field relationships.  If doing so is infeasible, please identify the database and supply information concerning the schemae and query language of the database, along with a detailed description of its export capabilities, so as to facilitate Plaintiffs crafting a query to extract and export responsive data.

   Documents that do not exist in a native electronic format or which require redaction of privileged content are hereby requested to be produced in searchable [.PDF or .TIFF] format with logical unitization preserved.

   Is this perfect? Not at all.  But it’s better, clearer and more likely to get the parties to hone in on forms before the data dump begins and the other side starts crying, “We’ve already given them a gazillion pages in TIFF, Your Honor!  One bite! One bite!”
   _

5. Optimally, requesting parties seeking discovery in similar classes of cases (e.g., MDLs) would strive to develop an agreed-upon, detailed production protocol that addresses the myriad issues that can be resolved anticipatorily, including a specification of system and application metadata fields to be produced in load files.  I hope to see a standardized set of Production Specifications emerge that can be supplied with an RFP or referenced from an authoritative source, but though I’ve seen a few attempts, nothing’s rung the bell yet.
   _
6. In practice, the terms “any and “all” rarely serve to broaden the scope of a request; but, they’re a lightning rod for objection.  If you don’t absolutely need to say “all” in every request, then please don’t.  If this worries you, add something in the preface to your Request like, “Requests for production herein should be read so as to encompass any and all items responsive to the request.”  Try to craft each request to sound as if it were written by a human being instead of a lawyer.  Less is more from the standpoint of compelling production.When it comes to ESI, if you must fish, use a spear, not a net.
   _
7. Another pet peeve of mine is “including but not limited to” when offering examples in a definition or request.  Can’t you just say “including” and add a preface that says, simply and one time, “examples of responsive forms or items set out in any request should not be construed to limit the scope of the request.”
   _
8. A well-crafted request should designate the medium of production.  It’s important not to confuse the FORM of production with the MEDIUM of production.  The latter is the mechanism the producing party will use to convey the electronic production to you and has no bearing on the form of items produced.You might employ language like:
   _
9. “Productions smaller than 10GB should be made using DVD recordable optical media.  Productions larger than 10GB but smaller than 128GB should be made using a flash/thumb drive or portable external hard drive.  Productions larger than 128GB should be made using a portable external hard drive. If flash/thumb drives or portable external hard drives are not available to Defendant, Plaintiff will provide same to Defendant upon request.”
   _
   There’s no magic formula at work here, I just picked a few numbers that seemed reasonable to me.  The language should evolve as the media evolves.  But, heavens to Betsy, if you’re expecting 100GB of data, don’t ask for (700MB) CDs or (4.7GB) DVDs!  Though some may point to the advantageous “read only” character of optical media, there’s got to be some practical cap on the number of optical disks proffered.
   _
10. You may want to specify how electronic documents are to be de-duplicated and how paper documents are to be imaged and OCR’ed.  Here again, requesting parties need a welll-crafted model production specification.  They may have to fight for such a  protocol to gain acceptance; but, that effort will pay off when less time and money is wasted fighting over botched productions.
    _
11. You should specifically address production exceptions (stuff that responding parties know or should know they have failed to produce or will fail to produce because of system flaws and limitations).  Opponents are unlikely to reveal such exceptions voluntarily.  I suggest interrogatories like these: 

    For each electronic system or index that will be searched to respond to discovery, please state:
    i.    The rules applied by the system to tokenize data so as to make it searchable as words in an index;
    ii.    The stop words used when documents, communications or ESI were added to the system or index;
    iii.    The number and nature of documents or communications in the system or index which are not searchable as a consequence of the system or index being unable to extract their full text or metadata; and
    iv.    Any limitation in the system or index, or in the search syntax to be employed, tending to limit or impair the effectiveness of keyword, Boolean or proximity search in identifying documents or communications that a reasonable person would understand to be responsive to the search.
    _

12. For the rationale behind these questions, please look at my article entitled, The Streetlight Effect in E-Discovery, at p. 252 of this collection of articles.
    _
13. If the parties have not settled on an agreed production protocol or you have not otherwise supplied a detailed production specification, I suggest adding provisions similar to the following, adapting the language to be consistent with your needs and to harmonize with the rest of the Request for production:

a.    Documents produced should be Bates numbered by naming the file produced to conform to the Bates number assigned to that file, supplying the original file name data in the delimited load file described below.

b.    Production should include a delimited load file supplying relevant system metadata field values for each document by Bates number.  The field values supplied should include (as applicable):

i.      Source file name (the original name of the item or file when collected from the source custodian or system);
ii.    Source file path (the fully qualified file path from root of the location from which the item was collected);
iii.   Last modified date (the last modified date of the item when collected from the source custodian or system);
iv.   Last modified time (the last modified time of the item when collected from the source custodian or system);
v.    Custodian or source (the unique identifier for the original custodian or source);
vi.   Document type;
vii.  Production File Path (the file path to the item from the root of the production media);
viii. MD5 hash (the MD5 hash value of the item as produced);
ix.   Redacted flag (an indication whether the content or metadata of the  item has been altered after its collection from the source custodian or system);
x.    Embedded Content Flag (an indication that the item contains embedded or hidden comments, content or tracked changes);
xi.   Hash deduplicated instances (by full path);
xii.  UTC Offset  (The UTC/GMT offset of the item’s modified date and time).

The following additional fields shall accompany production of e-mail messages:
xiii. To (Addressee(s) of the message);
xiv. From (the e-mail address of the person sending the message);
xv. CC (person(s) copied on the message);
xvi. BCC (person(s)blind copied on the message);
xvii. Date Sent (date the message was sent);
xviii. Time Sent (time the message was sent);
xix. Subject (subject line of the message);
xx. Date Received (date the message was received);
xxi. Time Received (time the message was received);
xxii. Attachments (the beginning bates numbers(s) of attachments, delimited by comma);
xxiii. Mail Folder Path (the path of the message from the root of the mail folder);
xxiv. Message ID (the Microsoft MAPI or similar unique message identifier).
The following additional fields shall accompany images of paper documents:
xxv. Beginning Bates Number (the beginning Bates number of the first page of the document);
xxvi. Ending Bates Number (the ending Bates Number for the first page of the document);
xxvii. Page Count (the total number of pages in the document);
xxviii. Location (the source box or other location identifier needed to trace the document to its source.

c.    Documents should be vertically de-duplicated by custodian using each document’s hash value. Near-deduplication should not be employed so as to suppress different versions of a document, notations, comments, tracked changes or application metadata.

 d.    Respond to each request for documents by listing the Bates numbers of  responsive documents produced.

 e.    For each document or other requested information that you assert is privileged, identify that document by its Bates number, stating the specific grounds for the claim of privilege the date of the document, the name, job title, and address of the person who prepared it; the name, address and job title of the person to whom it was addressed circulated, or who saw it; the name, job title, and address of the person now in possession of the document; a description of the subject matter of the document; the document’s present location; and the custodian for the document.

Did Atticus Finch Seek Scrolls?
This post has gone long.  There are just so very many things requesting parties can do to streamline discovery and lay the groundwork to get to the probative evidence more effectively and cost-effectively. The first of these is to re-examine how you approach requests for production.  Are you simply re-tasking creaky requests from days of yore?

The earliest cars resembled horse drawn carriages because they were modified carriages.  The automobile pioneers didn’t ask, “What would a car look like if we hadn’t started with carriages?”  It took decades for automobile design to shake off its horse collar.

Most of what we do in discovery today remains mired in yesteryear. We use requests and definitions numbly copied from someone who, lazy or apprehensive, numbly copied them from someone else…back in 1947. When was the last time the evidence in your case was a telegram or a dictation belt?  How much of the paper evidence used in your last case was not born digitally; i.e., it was entirely handwritten or typed onto paper?

I hear tell women got the vote, and they pipe water into houses now.

The language I’ve offered above isn’t built of magic words.  It’s just something I’ve composed on the fly, so I can’t point to case law that expressly approves same. Much of the totemic language that comprises the dated boilerplate of Requests for Production are just words someone like me thought might be a good idea thirty-, forty- or  fifty years ago.  Now, we treat it like scripture.  Forms are not your friend.  Don’t be afraid to create something better, something thoughtful, economical and contemporary: Let’s craft 21st century discovery targeting 21st century information.