Going Native: A Practical Guide to ESI in Native Format

On December 1, 2006, the Federal Rules of Civil Procedure were amended to establish rules to govern discovery of electronically stored information (ESI).[1] Courts nationwide have since issued scores of opinions to guide practitioners in applying the amended rules.[2] Some courts held that a party must produce native ESI in order to comply with Rule 34(b)(2)(E)(ii), which provides that unless otherwise agreed upon or ordered by the court, “(ii) [i]f a request does not specify a form for producing electronically stored information, a party must produce it in a form or forms in which it is ordinarily maintained or in a reasonably usable form or forms.”[3] 

For example, in White v. Graceland College Center for Professional Development & Lifelong Learning Inc.,[4] the producing party produced a PDF version of emails rather than the native version. The requesting party argued that the responding party’s production did not comply with Rule 34(b)(2)(E)(ii) because the responding party did not produce the emails in a form ordinarily maintained or in a reasonably usable form, thus preventing the requesting party from confirming email attachments.[5] The court held that the producing party’s conversion of the “emails and attachments to PDF documents and production of the PDF documents in paper format does not comply with the option to produce them in a reasonable usable form.”[6] Other courts have similarly held that the production of excel spreadsheets in native format is required in order to comply with Rule 34(b)(2)(E).[7] 

Native v. Static ESI 
A native file is ESI in a format that permits the user to modify the information. In contrast, a “static” file is ESI such as a PDF or TIFF file that cannot be modified.[8] Although courts sometimes require the production of electronic documents in native format, it may not always be best to request native documents.[9] Further, once a requesting party receives a native file, it is important to consider whether to use the ESI natively or statically.

One of the benefits to admitting a native file as evidence is that the fact-finder can consider a larger amount of information than if static ESI is admitted. For example, if the native file is a software program or Excel spreadsheet and the issue relates to the output of a program, a fact-finder may more easily understand the process through the ability to manipulate the ESI. Similarly, it allows the fact-finder to experience other aspects of the information that may be impossible with static ESI format (for example sight, sound, movement or speed).[10] The disadvantages to the admissibility of native format could include higher costs, the need for additional forms of technology and potential difficulty in preserving an evidentiary record.[11]

“Going native” or “live” in a courtroom or deposition is still a relatively novel concept, and the methods in which a practitioner “goes native” could vary tremendously. For example, if a central issue in the case involved who knew what and when, the party using the native email files (e.g., .pst) could use a laptop (just as they would for a PowerPoint presentation), open the native file and show the fact-finder (or a deponent or trial witness) the emails as they were saved.[12]

Although a practitioner may choose to “go native” in a courtroom or deposition, the practitioner does not necessarily need to admit the files natively. A practitioner could use the native file for demonstrative purposes only and admit static ESI exhibits for purposes of preserving a more traditional evidentiary record.

Practice Tips for Admitting Native Files 
As Judge Paul Grimm noted in a well-cited opinion, “[b]e careful what you ask for, the saying goes, because you might actually get it.” [13] In Lorraine, Judge Grimm denied both the plaintiffs’ and defendants’ motions for summary judgment, holding that both parties failed to observe the rules of evidence relating to ESI. Lorraine serves as a clear reminder that the rules of evidence have not changed, only the format of the evidence. Since technology changes rapidly, no one-size-fits-all approach exists, and practitioners should consider each piece of evidence specifically as it relates to the facts of each case.[14] Rules 901 and 902 of the Federal Rules of Evidence, which relate to authenticity, are particularly important with respect to ESI because of the complicated variations of ESI records or data; however, the ultimate question is the same for all types of evidence—is the record that which it purports to be? 

Authenticating a paperless electronic record, in principle, poses the same issue as for a paper record, the only difference being the format in which the record is maintained… [However,] the paperless electronic record involves a difference in the format of the record that presents more complicated variations on the authentication problem than for paper records. [15]
In addition to being mindful of the rules of evidence, before a request for a native file is made, practitioners should carefully consider how to label the files since the commonly used “bates stamp” will be impossible to use natively. Courts and commentators have recently discussed “native labeling” or non-bates stamp labeling methods for native files. [16] Some of these non-bates labeling methods include assignment of a number (for purposes of identifying the file as an exhibit), or use of a mutually agreeable “escrow” or third-party as a keeper of the original copy of the native files. Although each of these solutions, individually or combined, could be the right “label choice,” one of the most discussed and favored native file labels is the “hash” algorithm. 

A hash algorithm or “digital fingerprint” is a mathematical process or an encrypted algorithm that generates a unique alphanumeric value (often 32-64 characters long) to identify the total combination of bits and bytes that make up a particular computer file, group of files or even an entire hard drive.[17] Numerous types of hash algorithms exist, and the unique feature is that it is computationally infeasible for two files to produce the same hash value. As such, the use of a hash is ideal for practitioners when producing or admitting native ESI and could be of enormous assistance in authenticating native files.[18]

One commentator has urged practitioners to uniformly label hash algorithms, first by naming the native file by the name of the author of the file, then by using the number symbol (#), followed by the use of a shortened hash value (using the first and last three numbers of the hash value).[19] For example, if an email was sent by John Doe and the hash value was 4999ASDF1845975C10D9FFDF24564569, the hash would be labeled “John Doe #499.569.”

Summary 
A landmark study by the School of Information Management and Systems of the University of California at Berkeley estimated that more than 99 percent of information created and stored in 2001 was electronic.[20] The study further estimated that in 2003 31 billion emails and five billion instant messages were sent by the world—per day.[21] It is likely that you will “go native” in a courtroom during your career and when you do, it is important to remember these points:

1. Before requesting native format, consider what format best fits the client’s needs and how you will deal with native labeling;
2. Once you obtain native files, consider whether you will seek to admit the evidence natively or statically; and

Remember the lesson from Lorraine—apply the rules of evidence.