skip to content

Really Thinking Through the Form of Production: Dixon v. Experian Info. Solutions, Inc.

by Joshua Gilliland


Joshua Gilliland, of Bow Tie Law,

Magistrate Judge Paul Cherry understands ediscovery. More importantly, his opinions have the classic “IRAC” analysis of Issue, Rule, Analysis, and Conclusion. This makes Judge Cherry’s cases on the form of production—like Dixon v. Experian Info. Solutions, Inc.—very educational reading.

Form of Production Overview

A producing party can state the form of production in their discovery request, pursuant to Fed. R. Civ. P. 34(b)(1)(C). The procedures for producing ESI are as follows:

(i) A party must produce documents as they are kept in the usual course of business or must organize and label them to correspond to the categories in the request;

(ii) If 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; and

(iii) A party need not produce the same electronically stored information in more than one form.

Really Stating the Form of Production

Dixon v. Experian Info. Solutions, Inc., is a case involving consumer credit reports. The Plaintiff requested information from the Defendant’s proprietary database and was thoughtful in how they stated the form of production:

In accordance with Fed. R. Civ. P 34(b)(1)(C), Plaintiff requests that Defendant produce all electronically stored information which would be responsive to these Requests in native format unless that format is one which can only be read by Defendant’s proprietary software. If the requested electronically stored information can only be read by Defendant’s proprietary software and if that information can be exported into an electronic format which can be read by nonproprietary software (such as Microsoft Word, WordPerfect, or Pages for word processed information; Microsoft Outlook “pst” format or Mac Mail for email; Microsoft Office Access, Microsoft Excel or Mac Numbers for database information) then Plaintiff requests that such information be produced in that electronic format. With respect to Documents or Communications which already exist as .pdf files, copies of those .pdf files, including any metadata, should be produced.

The Plaintiff was extremely thorough in their request for production, further defining native file as generally meaning “…the original format of a type of electronically stored information in which such information was embodied at the time it was created by the software application used to create it.”

As You Can Guess, ESI Was Not Produced in Native File Format

Motions to compel are not filed because a producing party fully complied with a discovery request. In this case, the Defendant produced the ESI as unsearchable PDF’s. The Court noted that the Defendant did not address in their response or objection to the form of production. As such, the Court held that the Defendant waived any objections under Federal Rule of Civil Procedure Rule 34(b)(1)(C).

The Form of Production Dispute

The Plaintiff argued the Defendant producing ESI that was fully searchable in electronic format produced as static images severely restricted his ability to search or analyze the discovery.

The Plaintiff argued that the Defendant maintained “consumer disclosures” in a File One database, where the Defendant could run a query that would generate a report with the query results. The Plaintiff claimed the reports and data which generated the reports was in electronic format, thus should be produced natively.

The Defendant countered that they produced information from File One in litigation as 1) a “snapshot” of the credit information at the time of the request; and 2) an “Admin Report” that contained changes to the credit file over time.

The Defendant claimed that producing the data as native files would be unfairly prejudicial, because the data would be confusing to a layperson due to the coding. As such, the Defendant contended the data could be improperly used to confuse a jury at trial.

The Court rejected this argument on the grounds it was both speculation and a topic that could be addressed at trial with a motion in limine.

The Court then ordered the production of the consumer disclosures in native format. The Court further ordered the production of the “Admin Report” in native file format as originally requested, which had been produced as a scanned PDF of native files that had been printed.

Bow Tie Law Thoughts on Ediscovery

Judge Cherry is one of the unsung heroes of ediscovery. His opinions define the rules on the form of production and apply them to the facts of the case. For example, EEOC v. SVT, LLC, 2014 U.S. Dist. LEXIS 50114, 3-4 (N.D. Ind. Apr. 10, 2014) and Jannx Med. Sys. v. Methodist Hosps., Inc., 2010 U.S. Dist. LEXIS 122574 (N.D. Ind. Nov. 17, 2010) are both excellent “nuts and bolts” cases on the form of production. Dixon is a good case study where a requesting party was very thoughtful in their request for production. This served them well in successfully winning their motion to compel.

The major lesson here is that requesting parties should always carefully consider the form of production when drafting requests. The reason is simple: you want discovery suitable for review and analysis, and that can mean different things for different types of data.

While it is common to request production in native file format along with image files and searchable text (and searchable metadata fields), this is not always the most suitable—or reasonable—form of production. For example, producing parties might not be able to produce native files due to the need to redact confidential information, such as trade secrets, or personal identifiable information, such as Social Security numbers. It is very likely that productions will be “blended,” containing a mix of native files and static images with associated text.

That is why requesting parties should ensure that their review software is suited to the form(s) of production they’re requesting. Everlaw provides the ability to review documents as near-native images (as produced or generated by Everlaw), as text (as produced or extracted by Everlaw), and in the native file format.  Just as importantly, all of these views are rendered within the browser, without special plugins or downloads, empowering a document reviewer to quickly and easily switch between views without interrupting their workflow.