When it comes to ediscovery production, it’s absolutely advantageous to keep the end goal in mind from the outset. The duty to produce is explicitly outlined in the Federal Rules of Civil Procedure and most analogous State Rules. Although it’s the final step in discovery, it’s not something that should be put off until the end – you should be planning for your final production format throughout collection, data processing, and document review.

Interestingly, the Rules of Civil Procedure stop short of specifying a particular format for producing electronically stored information (ESI) and instead put the burden upon each party to “specify the form or forms in which electronically stored information is to be produced.”

That means you get what you ask for – but if you don’t ask for a specific format, then you’re stuck with whatever the other side decides to dump on you. (Technically, ESI should be produced in the “form or forms in which it is ordinarily maintained,” but that dictate often seems to be conveniently overlooked.)

In order to “specify the form or forms” of ESI production, you’ll need to actually have a discussion with opposing counsel. Attorneys seem to be hesitant to do this, maybe because they don’t know what to ask for, or maybe they’re nervous that reciprocal requests will be placed on them. Regardless of the reasons, you’re only wasting time and increasing costs when you avoid this step.

FRCP 26(f) requires parties to “confer as soon as practicable” about a discovery plan, including the form or forms in which ESI should be produced (FRCP 26(f)(3)(C)). Your state may or may not require a similar “meet and confer,” but you’re only hurting yourself and your client by ignoring this critical responsibility in litigation.

Production Language Defined

ESI: The acronym for Electronically Stored Information, or all electronic data collected for litigation.

Native File: Files that are in the format in which they were originally created. For example, Microsoft Word docs come as .DOC or .DOCX files, Excel spreadsheets are .XLS or .XLSX files, etc.

PST: The native format of an exported email inbox containing all email messages and data.

TIFF: A common file type that is an “image” of the native file.

OCR: Optical Character Recognition takes imaged documents, like TIFFs, and converts them into searchable text files.

Metadata: Often referred to as “data about data,” it is the information that describes the characteristics of ESI, hidden from direct view. It includes information such as author, recipient, creation date, modified date, and more.

Load File: A file used to import data into an ediscovery system. It defines document parameters for imaged documents and often contains metadata for all ESI it relates to.

See our full glossary for more ediscovery terminology >>>

Proactive Preparation for Ediscovery Production

We’re going to break down the four primary formats of ediscovery production – but first, there are two details you need to consider to be better prepared.

First, you need to have some knowledge of your client’s data – how they store data, access their files, host their communications (email, Slack, etc.) and their general data backup and archiving policies.

This will take a little work, but having a basic knowledge of how your client’s information is stored and managed will help tremendously when you’re conferring with opposing counsel about their production requests (that’s the “end” part). This discussion will also provide structure and guidelines for how you instruct your client on collecting and preserving their data (that’s the “beginning” part).

Second, note the Rules state “form or forms” of ediscovery production, which means you’re not stuck with a single “form” of production.

For example, you could request Microsoft Word documents as PDF files, but request Microsoft Excel spreadsheets in their native .XLSX format so you can see all the embedded metadata and formulas (see Williams v. Sprint/United Mgmt. Co., 230 F.R.D. 640 (D. Kan. 2005). In order to know what form or forms to request, you need to decide what tool or platform you’re going to use to review the files (e.g. Nextpoint) in case there are challenges on viewing certain files.

Form #1: Paper Production

Oh paper, “thou art more lovely and more temperate” than any cold and unloving piece of electronic mail. We know paper, we love paper, and apparently attorneys can’t get enough of paper. And we’re all familiar with the concept of producing a large stack of printed paper.

But it’s the “printed” aspect that is most concerning because emails are not “ordinarily maintained” as printed paper, nor are printed emails a “reasonably usable” method for review. In fact, when you print an email to paper, you’re stripping out the identifying metadata and making it non-searchable. Paper productions worked fine when paper was all we had (no email, no word processors, no computers, no mobile phones, no life), but it’s simply not viable or expedient today.

The force, however, is ever so strong with paper. It’s familiar, and the legal world says that once something is printed it can’t easily be modified, which is something we take great solace in. But when you reduce an electronic file into an 8½” x 11” sheet of pulverized tree pulp, it’s no longer searchable or usable unless you turn it back into a digital version by scanning it and hoping the OCR will be mostly accurate.

Form #2: Near-Paper Production

What if you could produce electronically stored information in paper-like form but still keep all the searchability and accompanying metadata?

The origins of this format come from the paper days, when we would scan in paper documents as individual images (TIFF files), but someone would laboriously “code” the images with identifying information such as author, recipient, subject line, document type (e.g. letter, invoice), source, etc. When it came time for production, you would bundle all those scanned images together with a spreadsheet containing all the identifying coding.

Today, we don’t scan paper, but we directly ingest electronic files, review them, and then create a similar production set consisting of TIFF images accompanied by searchable text files and a spreadsheet containing the extracted metadata (e.g. author, recipient, subject line, document type, date created, file extension, source file path, etc.).

This is known as a “load file,” which requires some expertise to load everything into a document review platform. The “load file” is a holdover from old technologies, but it is still a viable format when you need to produce files with redactions or other endorsements. If this is your agreed-upon form of production, part of the discussion you need to have with opposing counsel is which metadata fields will be included in the load file.

In Nextpoint, you can choose our “Production Export” option for this type of production, which is what we recommend for most evidence. All files will be produced as TIFF or JPEG files, and the export includes associated text and a load file with metadata.

Legal teams can also choose to produce a “PDF Export,” in which case the load file will include both the Bates stamping and metadata. Some legal teams may prefer to receive data as PDFs, especially if they don’t have specialized review software.

Form #3: Near-Native Production

This format balances on the edge of a mini-technicality, but it’s useful nonetheless. There are some cases where a native electronic file may need to be converted into another electronic format so that it can be reviewed more easily.

For example, most email communications from Microsoft Outlook are stored and extracted as .PST files, but in order to review the individual messages they are converted into separate .MSG or .EML files. While files like PDFs and TIFFs lose metadata unless a load file is included, the file types in near-native productions still include all of the embedded metadata and functionality. However, there is still a conversion involved, making this a “near-native” production.

Form #4: Native Production

As you might have guessed by now, a native file production is going to provide the most flexibility and usefulness. Native electronic files are produced in the format in which they were created and “ordinarily maintained.”

For example, a Microsoft Word document is produced as a .DOC or .DOCX file; a Microsoft Excel spreadsheet is produced as a .XLS or .XLSX file. Native electronic files are fully searchable by definition (without any need for

conversion) and contain all of the internal metadata. There are no image or file conversion costs, and all internal information is accessible (e.g. formulas in spreadsheets or speaker notes from PowerPoint presentations).

Just to be clear, producing emails or Microsoft Word documents as PDF files is NOT a “native” production. You are converting .PST or .MSG or .EML or .DOCX files into PDF files, which is close to the same as printing those emails to paper. This isn’t necessarily injurious, just know what you’re not getting.

While native productions are the easiest and simplest and most useful format for review and production, there is some pushback based on outdated, paper-based perspectives. Namely, how can we Bates stamp each page of an electronic file when there are no pages? The answer is there are no pages, and so we assign each file a unique “DocID” and stop worrying about “pages” (e.g. there are no pages in an email unless you hit the Print button).

There’s also a risk that someone would open the native file in the original software and unintentionally modify it (e.g. a .DOCX file in Microsoft Word). But that risk is completely mitigated when you use a tool like Nextpoint that properly preserves the file and prohibits any accidental edits or modifications.

A “Native Export” is the third option for productions in Nextpoint, which most teams use for file types that don’t image well, like Excel spreadsheets and audio/video files. This can be part of a primary Production Export, or it can be a separate production.

Production Checklist

• What format are the imaged files? (PDF, TIFF, JPEG)
• Is it the format you agreed on with opposing counsel?
• Is a searchable text file included?
• Is a load file included? Does it contain the necessary metadata?
• Are any native files included in the production?
• Are your redactions and privilege log complete?

Using the Proper Tool for Ediscovery Production

Don’t forget to keep the end (production) in mind from the beginning (collection), because if opposing counsel requests a specific form of production (e.g. native files) but you collected emails as PDF files, you will most likely be required to go back and re-collect and re-review at additional cost to you and your client.

Most importantly, you need to have the confidence that the tool you’re using to create production sets can accommodate the requested form of production. Nextpoint provides the tools for all forms of ediscovery production, complete with the option of setting up templates so you don’t have to start from the beginning every time.