A Practical Primer On Production Format Requests

The electronic format that electronically stored information (ESI) is produced in is a necessary component of e-discovery. This article offers a primer on production format issues by diagramming a template request in order to explain both the technical meaning and practical significance of the terms.

Too many litigators take a hands-off approach to production format requests. Some delegate writing the request to litigation support staff or the e-discovery vendor. Others reuse the same generic template in every case, while some lawyers even try to avoid the issue altogether by leaving the production format to the opposing party's discretion.

At first glance, the technical language used in production format requests might seem to justify at least the first of these approaches. It's certainly true that it's important for lawyers to collaborate with their technical support team in drafting format requests. It's critical that the production meet the technical specifications of the document review database. In addition, e-discovery professionals are a valuable knowledge resource in dealing with non-standard ESI data types. In a similar vein, templates are a convenient, time-saving tool when properly used as a starting point for drafting a request.

However, there are three compelling reasons that lawyers simply cannot afford to not pay close attention to production format requests. First, getting the technical terms wrong can be a costly mistake; cost that can and should be avoided. Second, lawyers must have a good grasp on both the technical and substantive aspects to effectively negotiate and argue production format request issues. Lastly, making an incomplete request runs the risk of missing valuable sources of electronic information.

General ESI

This includes: single page TIF endorsed with bates-numbers and confidentiality labels; document level text; delimited data file including the fields listed below; and a load file. MS Excel files, MS PowerPoint files, audio/video files, and other file types per agreement should be provided in native file format. For native file production, a Native Link field should be provided in the delimited data file.

Endorsed Images

The threshold decision about production format is whether to request image files or native files. A native file production is as-is, i.e., a Word document is produced as a DOCX file, an Excel spreadsheet is produced as an XLSX file, an e-mail message is produced as an MSG file, and so on. By contrast, in an image file production the native files are converted from their original format to an image file type; TIF and PDF are the two standard options for production images.

Most productions are image file productions. This industry-wide choice is driven by lawyers' overwhelming preference for bates-labels and confidentiality stamps, which can be endorsed (or burned) on each page of the converted image file. The labeling workaround for native file productions is to create new metadata fields for bates-number and confidentiality designation, and electronically link these new fields to the original native files in the production set.

The main argument against image file productions is that electronic information is lost in the native-to-image conversion. With the exception of the load file, the other parts of the template request are designed specifically to recapture this lost information.

Document Level Text

When a searchable native file like a Word document is converted to TIF or PDF it is rendered non-searchable. “Document level text” is a request that the source searchable text be extracted from the original native file and saved out as a new text file; the text file is linked to the associated image file in the production set.

If searchable text is not produced, then the requesting party will have to assume the added- and unnecessary- expense of recreating it electronically by using the production image file as a source.

Delimited Data File With Field List

The purpose of the “delimited data file” is twofold. First, it is a request for the metadata that is likewise lost in the native-to-image conversion. What can be described as substantive-type metadata fields include author, filename, date- and timestamps (e.g., created, modified, and sent dates), and e-mail subject line and sender/recipient information. Technical-type metadata fields include file extension, page count, file size, and relationship information for e-mail messages and their attachments. Second, a subset of the data file fields is technical information about the production that is required by the document review database; the link between an image file and its associated document level text file is an example.

Many metadata fields are useful for running name, date, and keyword searches. Fields like created date and author are a potentially critical source of evidence about the what, when, and who of the producing party's knowledge of the facts of the case. In addition, metadata is important in authenticating records.

Most of the information in metadata fields is only available in metadata. An image production that does not include metadata is akin to a paper production with the names and dates redacted.

Load File

The “load file” is used in loading the production into the requesting party's document review database. Litigation support staff or the e-discovery vendor can provide the appropriate technical specifications for requesting the load file.

Native File Format

Native-to-image conversion is problematic for certain file types. An obvious example is audio/video files, which cannot be converted at all. Excel spreadsheets are a major issue in corporate discovery; as a practical matter they're difficult to read when not viewed in native file format and embedded information like formulas is lost in conversion. The “native file format” is a request for a partial native file production of file types where an image production simply doesn't make sense.

Scanned Paper Files

Scanned paper files should be logically unitized. Fields for custodian, attachment information, and file folder should be provided in the delimited data file.

Logical Unitization

“Logical unitization” is a request that each paper document be scanned as a single TIF or PDF and not, for instance, by scanning the full contents of a multi-document file folder as a single image file. If the documents are not logically unitized, then the requesting party must bear the unnecessary expense of electronically splitting up the production image into its constituent parts. Moreover, some degree of guesswork is involved in determining document breaks after the fact.

Databases

The parties will confer as to production format for ESI sourced from relational databases. The default format for embedded or linked native files (e.g., MS Word files, PDF files) is the general ESI production format given above.

ESI from Databases

Database ESI poses a unique production format challenge. A report is typically the best option for database production; however, the content and format of the report should be customized to the database at issue. The requesting party needs information about the available data entry fields, query capabilities, and reporting options in order to specify the optimal production format. Trying to shoehorn database ESI into the general ESI request is likely to result in production that is neither usable in format nor complete in content.

Native Files

The report option does not apply to PDFs and other electronic files that have been uploaded to a database. These do come within the general ESI category with the proviso that, similar to scanned files, the delimited data file field list should be supplemented to take into account any relevant database metadata.

Mobile Device Data

Reports of extracted mobile device data (e.g., SMS, Call Logs, Contacts) should be produced in as an Excel spreadsheet or comparable searchable file type. Camera photos, audio/video files, voicemails, and other electronic files should be produced in native file format.

Extracted Data Reports

Mobile device ESI is another special case. Phone data, like text messages and call logs, is produced in reports, although the reporting options vary according to the capabilities of the mobile forensics software program that was used to collect the data. The key point is to request a searchable report. Pictures and other electronic files saved on the phone handset or SD card can be requested in native format or according to the general ESI production format request.

Conclusion

It's important for all litigators to understand the meaning and significance of the technical terms in a production format request. A production format request that is incomplete or uses the wrong technical language can easily result in missed evidence and unnecessary costs. While the risks are higher for the requesting party, the producing party can also run into cost problems by agreeing to an infeasible or burdensome production format.

Helen Geib is general counsel for Qdiscovery. She practiced law for seven years in the intellectual property litigation department of a leading Midwest law firm where her responsibilities included managing large-scale discovery and motion practice. She brings that experience and perspective to her work as an e-discovery consultant where she also provides trial consulting services in civil and criminal cases.

The electronic format that electronically stored information (ESI) is produced in is a necessary component of e-discovery. This article offers a primer on production format issues by diagramming a template request in order to explain both the technical meaning and practical significance of the terms.

Too many litigators take a hands-off approach to production format requests. Some delegate writing the request to litigation support staff or the e-discovery vendor. Others reuse the same generic template in every case, while some lawyers even try to avoid the issue altogether by leaving the production format to the opposing party's discretion.

At first glance, the technical language used in production format requests might seem to justify at least the first of these approaches. It's certainly true that it's important for lawyers to collaborate with their technical support team in drafting format requests. It's critical that the production meet the technical specifications of the document review database. In addition, e-discovery professionals are a valuable knowledge resource in dealing with non-standard ESI data types. In a similar vein, templates are a convenient, time-saving tool when properly used as a starting point for drafting a request.

However, there are three compelling reasons that lawyers simply cannot afford to not pay close attention to production format requests. First, getting the technical terms wrong can be a costly mistake; cost that can and should be avoided. Second, lawyers must have a good grasp on both the technical and substantive aspects to effectively negotiate and argue production format request issues. Lastly, making an incomplete request runs the risk of missing valuable sources of electronic information.

General ESI

This includes: single page TIF endorsed with bates-numbers and confidentiality labels; document level text; delimited data file including the fields listed below; and a load file. MS Excel files, MS PowerPoint files, audio/video files, and other file types per agreement should be provided in native file format. For native file production, a Native Link field should be provided in the delimited data file.

Endorsed Images

The threshold decision about production format is whether to request image files or native files. A native file production is as-is, i.e., a Word document is produced as a DOCX file, an Excel spreadsheet is produced as an XLSX file, an e-mail message is produced as an MSG file, and so on. By contrast, in an image file production the native files are converted from their original format to an image file type; TIF and PDF are the two standard options for production images.

Most productions are image file productions. This industry-wide choice is driven by lawyers' overwhelming preference for bates-labels and confidentiality stamps, which can be endorsed (or burned) on each page of the converted image file. The labeling workaround for native file productions is to create new metadata fields for bates-number and confidentiality designation, and electronically link these new fields to the original native files in the production set.

The main argument against image file productions is that electronic information is lost in the native-to-image conversion. With the exception of the load file, the other parts of the template request are designed specifically to recapture this lost information.

Document Level Text

When a searchable native file like a Word document is converted to TIF or PDF it is rendered non-searchable. “Document level text” is a request that the source searchable text be extracted from the original native file and saved out as a new text file; the text file is linked to the associated image file in the production set.

If searchable text is not produced, then the requesting party will have to assume the added- and unnecessary- expense of recreating it electronically by using the production image file as a source.

Delimited Data File With Field List

The purpose of the “delimited data file” is twofold. First, it is a request for the metadata that is likewise lost in the native-to-image conversion. What can be described as substantive-type metadata fields include author, filename, date- and timestamps (e.g., created, modified, and sent dates), and e-mail subject line and sender/recipient information. Technical-type metadata fields include file extension, page count, file size, and relationship information for e-mail messages and their attachments. Second, a subset of the data file fields is technical information about the production that is required by the document review database; the link between an image file and its associated document level text file is an example.

Many metadata fields are useful for running name, date, and keyword searches. Fields like created date and author are a potentially critical source of evidence about the what, when, and who of the producing party's knowledge of the facts of the case. In addition, metadata is important in authenticating records.

Most of the information in metadata fields is only available in metadata. An image production that does not include metadata is akin to a paper production with the names and dates redacted.

Load File

The “load file” is used in loading the production into the requesting party's document review database. Litigation support staff or the e-discovery vendor can provide the appropriate technical specifications for requesting the load file.

Native File Format

Native-to-image conversion is problematic for certain file types. An obvious example is audio/video files, which cannot be converted at all. Excel spreadsheets are a major issue in corporate discovery; as a practical matter they're difficult to read when not viewed in native file format and embedded information like formulas is lost in conversion. The “native file format” is a request for a partial native file production of file types where an image production simply doesn't make sense.

Scanned Paper Files

Scanned paper files should be logically unitized. Fields for custodian, attachment information, and file folder should be provided in the delimited data file.

Logical Unitization

“Logical unitization” is a request that each paper document be scanned as a single TIF or PDF and not, for instance, by scanning the full contents of a multi-document file folder as a single image file. If the documents are not logically unitized, then the requesting party must bear the unnecessary expense of electronically splitting up the production image into its constituent parts. Moreover, some degree of guesswork is involved in determining document breaks after the fact.

Databases

The parties will confer as to production format for ESI sourced from relational databases. The default format for embedded or linked native files (e.g., MS Word files, PDF files) is the general ESI production format given above.

ESI from Databases

Database ESI poses a unique production format challenge. A report is typically the best option for database production; however, the content and format of the report should be customized to the database at issue. The requesting party needs information about the available data entry fields, query capabilities, and reporting options in order to specify the optimal production format. Trying to shoehorn database ESI into the general ESI request is likely to result in production that is neither usable in format nor complete in content.

Native Files

The report option does not apply to PDFs and other electronic files that have been uploaded to a database. These do come within the general ESI category with the proviso that, similar to scanned files, the delimited data file field list should be supplemented to take into account any relevant database metadata.

Mobile Device Data

Reports of extracted mobile device data (e.g., SMS, Call Logs, Contacts) should be produced in as an Excel spreadsheet or comparable searchable file type. Camera photos, audio/video files, voicemails, and other electronic files should be produced in native file format.

Extracted Data Reports

Mobile device ESI is another special case. Phone data, like text messages and call logs, is produced in reports, although the reporting options vary according to the capabilities of the mobile forensics software program that was used to collect the data. The key point is to request a searchable report. Pictures and other electronic files saved on the phone handset or SD card can be requested in native format or according to the general ESI production format request.

Conclusion

It's important for all litigators to understand the meaning and significance of the technical terms in a production format request. A production format request that is incomplete or uses the wrong technical language can easily result in missed evidence and unnecessary costs. While the risks are higher for the requesting party, the producing party can also run into cost problems by agreeing to an infeasible or burdensome production format.

Helen Geib is general counsel for Qdiscovery. She practiced law for seven years in the intellectual property litigation department of a leading Midwest law firm where her responsibilities included managing large-scale discovery and motion practice. She brings that experience and perspective to her work as an e-discovery consultant where she also provides trial consulting services in civil and criminal cases.