#CaseoftheWeekCase Law

Episode 113: Want to Know Why Metadata Matters in eDiscovery? Listen up.

In Episode 113, our CEO, Kelly Twigger discusses the importance of planning for metadata for each source of ESI and how not getting metadata can impact a party’s ability to review and analyze produced information.


Introduction

Welcome to this week’s episode of our Case of the Week series brought to you by eDiscovery Assistant in partnership with ACEDS. eDiscovery Assistant is a SaaS based platform and knowledge center that helps lawyers and legal professionals leverage the power of ESI as evidence. It is the only legal research database devoted exclusively to eDiscovery case law.

My name is Kelly Twigger. I am the CEO and founder at eDiscovery Assistant, as well as the principal at ESI Attorneys. Each week, I choose a recent decision in eDiscovery case law from our eDiscovery Assistant database and talk to you about the practical implications, what it means for you, your practice, your clients, and how to do discovery of ESI better.

The bulk of our learning in eDiscovery comes from case law. Unlike any other substantive area in the law, the constantly evolving landscape of technology means that the trial courts at both the federal and state levels are regularly issuing new opinions on parties’ obligations around ESI. Our goal here today is to look at the recent decision that we’re talking about, and to really delve into how you can leverage what you’re learning from that decision every day for your clients.

Before we dive in, if you haven’t yet had a chance to grab our 2022 Case Law Report, download a copy of that for your perusal. Each of the decisions in eDiscovery Assistant is a public link, meaning that you can link to those decisions in your writing. You can also review the full text of the decision without having a subscription to log in.

Doug Austin of eDiscovery today, is one of our partners. Here is a link to Doug’s post regarding the decision we cover in this blog.

Background

This week’s decision comes to us from the Hoehl Family Found. v. Roberts. This decision is from United States District Judge Geoffrey Crawford in the District of Vermont from April 13, 2023, just a couple of months ago. Judge Crawford has 16 decisions in our database, including one other decision on this same matter.

As always, we tag each of the decisions in our eDiscovery Assistant database with our proprietary issue structure. The issues tagged on this decision include privilege log, failure to produce, proportionality, cost recovery, redaction, waiver, claw back, metadata, form of production, manner of production, native format, and in camera review. A number of issues going on in this case. We’re going to focus in specifically on the ESI related issues to metadata and the language of the agreements between the parties.

Facts

The underlying dispute here involves a challenge over specific investments made by the defendants on behalf of the Foundation. We are currently before the court on two separate motions to compel.

The first was raised in January 2023, in which the Foundation seeks to compel the defendants to produce documents that the Foundation asserts were improperly claimed as privilege. The second motion was filed in February of 2023, which includes four separate issues, two of which involve form and manner of production of ESI that we’re going to cover in detail. In those two issues, on the first, the Foundation contends that the defendants have improperly produced documents without original metadata and in a manner other than the way the defendants kept the documents in the usual course of business. Secondly, the Foundation asks the court to compel defendants to produce attachments that are missing from a number of documents, and to produce a smaller number of documents that are not readable due to technical problems.

Let’s talk a little bit about the agreements between the parties. The parties did enter into an ESI protocol that was signed off on by the court here. That protocol included language that, “for any production made in non-native format, the producing party shall preserve the integrity of the underlying ESI, including original formatting, file structure, i.e., files attached to email, and metadata.”

In addition, the Foundation’s request for production to defendants included the following instructions as noted by the Court:

“Paragraph N of the definitions and general instructions section defined document to include all metadata and hidden data”, such as that maintained by an application program and metadata maintained about a file by the operating system or other programs. The definition further specified, “for the avoidance of doubt, metadata and hidden data include without limitation, the computer or server name and fully qualified location path upon which the electronically stored information was located, the dates and times associated with the creation, modification, and last access to the electronically stored information, and to the extent they exist, author name or initials, company or organization name, names of previous document authors, document revisions and versions, hidden text or cells, template information, other file properties and summary information, non visible portions or embedded objects, personalized views, and comments.” That’s all from paragraph N.

Paragraph Z then goes on to state, “electronically stored information shall be produced in a format that preserves all metadata. For any ESI productions made in non-native format, you should preserve the integrity of the underlying ESI, including original formatting, file structure, and metadata. Unless otherwise agreed to by the parties, files that are not easily converted to image format, such as spreadsheet audio and video files, shall be produced in native format.”

With those two sets of instructions in the ESI protocol and the requests for production, the defendants then began preserving, collecting, and producing documents through a service provider. They started productions in February of 2021 and continued rolling productions for about a year, which resulted in the production of about 400,000 documents. The bulk of the information that was produced was email. I want you to keep in mind as we’re talking about the time here, we’re talking about 2021 documents. Those are documents from 2021 or earlier. We’re not really in the issue yet of collaboration tools. We’re still talking about bulk email. And that’s something to keep in mind because sometimes I find that these days we’re letting issues with email slip a bit, and that’s not a good idea.

Three months after the initial production from the defendants, the Foundation wrote to the defendants regarding deficiencies in the metadata for more than 9,500 files that were missing file names and extensions — making the data harder to filter and search — and more than 5,500 documents that had incorrect metadata in the date created field. Side note here, whenever we see documents with the same date created field, the same date in the date created field, or the date that is close to the production of documents, we know that those documents were moved prior to collection, causing that field to update to the date they were moved. In this case, that would mean that the date was updated for those 5,500 documents prior to collection.

At the time, the defense responded and said, basically, “we don’t know what you mean. We’ve provided you all those dates, plus we’ve also provided date created and other dates that you should be able to use.” The Foundation continued to object. Sure enough, a year later at a meet and confer, “the Foundation’s counsel asserts that the parties discussed how original metadata had not been retained because defendants moved documents from where they were stored in the ordinary course of business to intermediary folders in preparation for document production.” The Foundation asserted that “defendant’s counsel acknowledged that defendants moved documents to new folders in order to then transmit documents to their counsel for document review prior to production, and that metadata was stripped during this process.”

As a fix, the Foundation counsel requested that the folder tree for the file structure for those documents be provided in order to allow them to map documents and determine which requests the data that had been produced was responsive to. Defendants refused to provide the file tree. At a later point, prior to the resolution of these motions to compel, the defendants did produce a spreadsheet with file path metadata that could be loaded by the Foundation over the existing production data, but that sheet failed to contain all of the necessary metadata and clearly showed that the files had been moved prior to collection in violation of the instructions and the ESI protocol.

Those are the facts that are before us on these motions to compel.

Analysis

The Court’s analysis starts with addressing the timeliness and the waiver aspects of the issue, and it really addresses those in pretty quick fashion. It finds that the Foundation asserted their objections timely by responding a few months after the initial production and did not waive them.

Next, the Court considers whether the burden on the defendants to produce the missing metadata is too burdensome. The court notes that the Foundation cannot search or review associated metadata that has not been produced, and that the Foundation seeks the metadata as an aid for organizing the productions that it has received from the defendants. There’s an important quote here from the court. I really want you to focus on this because we’ve been seeing more and more decisions over the last 18 months from courts discussing the importance of metadata. This is an enormous switch from the last 5 to 10 years. We have seen lots of courts say that TIFF images are just fine for production and providing the accompanying metadata, but we haven’t gotten into detailed disputes on metadata the way that we have been over the last 18 months.

This is an important quote, so pay attention to this one:

“Notably, file system metadata makes electronic documents more functional because it significantly improves a party’s ability to access, search, and sort large numbers of documents efficiently. In its reply brief, the Foundation confirms that it seeks the organizational tools to understand the 400,000 plus pages of documents it has received.”

That’s an important quote because it shows that the Court recognizes the value of the metadata for the receiving party. That’s not something that we’ve seen a lot of in the previous decade. It’s really something that’s only come about in the last 18 months, two years. It’s noteworthy and something that you’re going to want to start including in your motions.

The last issue that the court addresses here is that of the privilege log and 138 documents that were clawed back by defendants. As we’ve seen multiple times in ediscovery case law recently, the Court here orders the defendants to provide those documents for in camera review and rejected the defendant’s argument that the Foundation had waived its right to object.

The court also looked at a separate 150,000 documents that defendants had redacted but failed to provide the basis for redaction in their production. They redacted documents based on attorney-client privilege and confidentiality but did not provide the basis for that redaction in the metadata or as part of the production to the Foundation. We’ve discussed this issue before, too, and this is another piece that needs to be provided for in the ESI protocol. Redactions are just a whole category of information that needs to be provided for. What are the categories that you’re going to redact based on? How will those be noted? Will there be a specific metadata field indicating that there is a redaction applied to a document and a separate metadata field for the basis?

I wrote a specific section in our ESI protocol series on our blog on how to do this effectively, and you can read that here. Here, the Court ordered the defendants to review the documents with the redactions and to supply a report indicating which redactions are for privilege. That’s a little bit less than we might otherwise hope for, but you need to ask for that in your ESI protocol.

Takeaways

We have a number of takeaways, and they’re really important ones for being able to manage data effectively when you receive it. The bulk of the data here was email. I mentioned that earlier that this is a case from 2021, and likely the data is even older than 2021. It’s not a case for 2023 where we’re talking about collaboration sources of data or dealing with pointers in email. Most litigations are still looking backwards, and the bulk of data is still email. Don’t overlook the importance of making sure that you’re collecting it in a way that allows you to provide what is required under both the ESI protocol, and, in this case, the instructions on the requests for production.

To me, this case is a prime example of what I call the “ediscovery disconnect” — where the lawyers draft the language of the ESI protocol and receive the RFPs, but don’t supervise the preservation and collection of documents. Here, the language of the protocol and the instructions of the RFP specifically request data fields that were modified by the defendants moving the data to be captured to a holding folder. We’re well past the stage of not knowing what changes metadata fields — or I guess I should say that courts are well past knowing that — and if you don’t know it, you need to start learning pretty quickly. This case is a prime example. When you move data to an alternative place before it is collected, you will change the date modified for that metadata field for that document.

My view of the way that the party structured instructions here is that it would be simpler to put all of that information in the ESI protocol versus separately in the requests for production. It’s one place for the parties to refer to and to provide to your folks for preservation and collection. Most of your service providers or your litigation support professionals are going to ask you for a copy of the ESI protocol. Many will ask you for any requests for production that have been provided in case there are additional instructions, but not all of them. If you have everything in the ESI protocol, that’s just one place for everybody to refer to, and it’s one place just for the court to refer to. I just think they’re better placed in the ESI protocol, but obviously here there were very clear instructions in the request for production that the court looked at, and you’re on the hook for those. If you’re the party receiving requests for production with extensive instructions that you need to follow, make sure that you’re providing them to the people who need them so it can be done correctly. The ESI protocol here didn’t provide the specificity about that particular metadata field that was changed by moving that folder. Otherwise, the service provider probably could have notified the client and you might have had to go back and recollect that information from the actual location rather than the holding place.

Early review of the documents, metadata and attachments is key. That’s one of our core tenets here on the Case of the Week. The Foundation did that here. Following the 2021 production, the Foundation identified the lack of metadata, attachments and other issues and raised them within a couple of months with the other side. They also did an excellent job of raising the issues with the privilege log in a timely manner. That’s key. You have to look at the data very quickly after you receive it.

Document, document, document. The Foundation here puts itself in a solid position on its motions to compel because it raised those issues in writing and the court had that correspondence to be able to look at in determining whether issues had been raised and whether they had been done so in a timely manner. Both parties tried to argue timeliness and waiver, and the court dismissed both parties arguments because of the correspondence that existed.

The quote here from the Court demonstrates that metadata is really crucial to a receiving party to be able to parse and understand the data that’s being produced. That’s the quote that came up earlier where the Court noted the importance of metadata and electronic information. Good project managers that are dealing with incoming productions, or paralegals, or whoever’s handling it should have a list of filters and searches that they run to understand the quality and organization of the data provided. And finding those holes is pretty easy if you have that set list of information. Give your PM a day or two to look through the data and really understand what’s good about the production, what’s bad about the production, and what needs to be addressed in order to make sure that you have all the information necessary. We’ve talked about it many times on Case of the Week that if you don’t have the documents you need, when you go to build on that by taking depositions, following up with additional requests for production, you find yourself in a huge hole and oftentimes outside the scope of the timeline for discovery.

Because courts now require that you not only provide requests for production with enough time for the other side to respond, you also have to provide them enough time to respond and you to be able to follow up on any objections you have to their response. That means it has to be done quickly. You can’t sit on discovery anymore.

The Court here found that by failing to put produce documents with complete and accurate metadata, that the defendants fell short of their discovery obligations. Because the Foundation sought metadata for non-email documents, the Court really understood that the metadata issues related to a set of approximately 10,000 documents and not the entire 400,000 page production. The court noted that the Foundation was directed to send the defendants a list of the subset of documents in order to supply a complete and accurate metadata for those documents. That imposed some burden on the defendants, but as the court noted, that was “a function of the way in which defendants chose to respond to the RFPs in the first place.” Basically, the court said, you dug this hole and now you have to get yourself out. They didn’t have a lot of sympathy for the defendant’s position that they had already complied with producing information — they were going to have to go back and recollect metadata.

This case has a number of important takeaways for you to discuss with your team. We feel like these are many of the basic issues in dealing with ediscovery appropriately, but the reality is that as parties and courts become more savvy with data and our volumes of data continue to increase, metadata is the key to allowing a receiving party to parse and review productions effectively. The Rules provide for it if you ask for it, so make sure you do.

Conclusion

That’s our Case of the Week for this week. Thank you so much for joining me. We’re back again next week with another decision from our eDiscovery Assistant database. As always, if you have a suggestion for a case to be covered on Case of the Week, drop me a line. If you’d like to receive the Case of the Week delivered directly to your inbox via our weekly newsletter, you can sign up on our blog. If you’re interested in doing a free trial of our case law and resource database, you can sign up to get started.

Thanks so much, and have a great week.



Categories
Archives
Privacy Settings
We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
Youtube
Consent to display content from - Youtube
Vimeo
Consent to display content from - Vimeo
Google Maps
Consent to display content from - Google
Spotify
Consent to display content from - Spotify
Sound Cloud
Consent to display content from - Sound