The following is Part VII in a multi-part series on how to draft and leverage an ESI protocol in any litigation. Part I of our series discussed the When, How and Why in planning for and creating your ESI protocol. Part II addressed the Key Components of an ESI Protocol, Part III walked through the Top 10 Situations You Can Avoid with a Protocol, and Part IV discussed Planning for the Production of Social Media. Part V covered the importance of including Manner of Production in your protocols. Part VI discussed the value of metadata and what to ask for.
In conjunction with this series, eDiscovery Assistant has created a new section in Checklists and Forms titled ESI Protocols that will include new content with each part of this series. That section includes sample ESI protocols, checklists on what to include and a list of metadata fields for inclusion in your protocol.
If you’ve drafted an ESI protocol, you know that form of production—i.e. the format in which you agree to receive data for each type of ESI at issue—is one of the main reasons that protocols are so key. Absent a written agreement on form of production, or specific instructions in the requests for production, Rule 34 of the Federal Rules of Civil Procedure allows a producing party to produce data in any reasonable format.
What is a reasonable format? That issue is still open. Some courts have held TIFF images and load files are reasonable, others have held non-searchable pdfs are reasonable (yes, I agree with your incredulous expression). Only the most progressive courts have required native production.
You have an opportunity to take Rule 34’s reasonable format language out of the equation by drafting a protocol that sets out exactly how the parties will deal with each issue on form of production. There are many issues to consider, and form of production is absolutely NOT a cut and paste job from your previous protocol.
As with each section of the protocol that we’ve discussed in this series, the form of production section needs to 1) address each of the issues on form for each of the types of ESI that you expect to have in your case, 2) to take into account the review platform you will use and 3) consider what you need for how you want to present information at trial. We’ll focus on 1 and 2 for this post and revisit trial presentation in a later post.
The most crucial part of form of production is to think through exactly how specific sections of your protocol will play out in practice, and make decisions about what you want and how you’ll use the data when you receive ESI. If thinking through how you will use ESI at trial is not something you know or understand, talk through what you want to have happen with your discovery counsel, litigation support or service provider and get feedback on how to accomplish what you need. As is always the case in ediscovery, the more thought you put in upfront, the less problems you’ll have later.
Form of production is generally a heading in a protocol, or a separate section, depending on how you set up your document. For each protocol, consider whether and how to include each of the following elements and how they play into what you need for your case and the technical requirements of your ediscovery review platform:
- No downgrading of usability of data. Generally, we provide that ESI will be produced in the form specified in the protocol and that no producing party can reformat, scrub, or alter ESI to intentionally downgrade its usability. That can mean converting data that makes images fuzzier, hides text or alters data in any way that precludes the receiving party from having the same reasonably useable data that the producing party can use.
- Specifics on form of production for individual types of data. This can get complex when you have cases involving source code, specific databases, social media, mobile devices, text messages, instant messaging or other cloud based applications. While we all know what TIFF images plus a load file means, you need to make sure you provide the exact specifications on the size of images, structure of the load file and the other technical specifications that your team needs for the platform you are using. We generally provide different specs based on the source of ESI — think Snapchat, Twitter, WhatsApp, etc.
- If you are requesting TIFF Images with a load file, you need a separate paragraph that details what types of documents will be produced natively. Typically, this includes PPT, XLS, CSV, Audio, Video, all image files, and non-standard document formats. Placeholders with bates labeled slip sheets are always key when documents are produced natively so that you know when you are viewing the images in document format. The slipsheet will show up telling you that the document was produced natively, so you can click to the native viewer or download the document for viewing.
- Family relationships. Generally, you want to preserve parent-child relationships but you need to also provide how to deal with family members when one member is privileged or needs to be withheld for other reasons like privacy or confidentiality of third parties (hint, put them on privilege log). How to deal with non-responsive documents in families is another issue and one to address in the Form of Production section of the protocol.
- Metadata fields. Most often, we see metadata in chart form as we discussed in Part VI of our series that addresses ALL of the metadata fields for each type of ESI and includes the Field order for loading, Field Name, Description of the Field, and an example of how the data will appear in production. For example, in Part IV of this series on social media, we talked about outlining the metadata needed for each platform that you would want. Just this week on our #caseoftheweek series, we talked about Snapchat and where information lives in that platform. Know your sources of ESI and plan for the specific metadata fields you need for each source.
- No obligation to manually code fields. Back in 1997, yes, I have been practicing that long, we printed emails and coded them manually into Summation. Now that we produce metadata, that is no longer needed as a general rule. But it’s helpful to state with specificity that fields that are not automatically generated by the processing of ESI or do not exist as metadata need not be manually coded. The exception is the following fields: BegBates, EndBates, BegAttach and EndAttach. You need bates numbers to match up documents, so don’t forget that piece.
- Extracted Text. This can be a separate paragraph or added to the form for each type of ESI. Wherever you include it, the goal is to provide that the parties shall provide extracted text for all files that originated in electronic form. If extracted text is not available, the producing party should OCR documents and provide OCR text, and OCR text should be provided for any documents that originated in hard copy but are being scanned and produced electronically.
- De-NISTing documents. The National Institute of Standards & Technology (NIST) maintains an industry standard list of file types that are not relevant for ediscovery purposes. It includes things like operating system files, etc. and is pre-loaded into your review platform such that when data is loaded, it will De-NIST or remove those file types that should be excluded.
- As a sub-category here, oftentimes parties will exclude additional file types, like signatures from emails, that are junk files (they don’t contain any material information). You can agree on the parameters of this limitation and also include language that if a receiving party can show a need for information in those file extensions, it may request them.
- Redactions. How you handle redactions depends on what you will need redacted. Is your case one where unrelated, confidential business information may be redacted? If so, you need to provide how a party identifies that information in the redaction box, and whether that information may be logged. Plan for each type of redaction that you may have. The protocol should specify what language should be used in the redaction box for privilege and work product as well.
- Bates Numbers and Confidentiality. Address the range for bates nos. and abbreviations for the parties to use in identifying documents and stay consistent throughout the case. We put bates nos. in the lower right corner and confidentiality designations in the lower left. Make sure your system starts at the next number every time you run a production. However you position these items on the document, be sure to articulate it in the protocol so there can be no questions. Make sure to reference your protective order on file, or include the levels of confidentiality in the protocol (confidential, highly confidential, attorneys eyes only). Pay attention to apostrophes and makes sure lit support follows what you include. We’ve had counsel complain that we used Attorneys’ Eyes Only sometimes and Attorneys Eyes Only others. Yes, really.
- De-duplication. Decide on what type of de-duplication you want—global is the most common using the hash value of the document so that you eliminate exact duplicates. There are several other types of de-duplication that you can run once you receive data to expedite review, but global de-dupe is the best generally.
Form of production is the key component to getting and using data constructively in litigation. If you want to capitalize on using the newest technology to create efficiencies in review and production, you need data in the right formats. Go through your existing protocols and make sure you incorporate each of these elements in a way that works for ESI in your case. It may be simple, or stunningly complex—it all depends on the case. In our next post, we’ll talk about how form of production can impact your case and situations you’ll want to avoid.
Now, get drafting. Even if you keep it in your back pocket for your next case. And head on over to Part VIII in this series where we discuss crafting a process for search terms that works for your case.
