I. Procedural Background

By Order dated February 14, 2019, the Honorable Cynthia M. Rufe appointed the undersigned, Daniel L. Regard, as Special Discovery Master for ESI in this matter. (Doc. No. 854; Pretrial Order No. 74.) This appointment was made pursuant to Pretrial Order Nos. 49, 52, 54, and 68. (Doc Nos. 667, 688, 698, 823 respectively.) The Court specifies in Pretrial Order No. 49 that:

“[i]f a Master is unable to succeed in resolving a particular dispute informally, he or she will be authorized to render a written report and recommendation to the Court after a fair and full review of the participating parties’ and nonparties’ respective positions.”

(Doc No. 667.)

My appointment followed months of negotiations between the parties on the terms of an Electronically Stored Information (ESI) Protocol. (Doc No. 583.) While the parties reached an agreement on most of the Protocol, they came to an impasse on three technical, ESI issues: 1) the use of thread suppression, 2) the logging of email threads with privileged content, and 3) the production of the “CustodianOtherDirectory” field.

The parties excellently briefed their positions with accompanying case law and attachments. (Doc. Nos. 584, 585, 587, 588.) On April 4, 2019, Special Master David Marion and I held a conference with the parties to discuss the open ESI issues. Both Plaintiffs and Defendants counsel made well-presented arguments for their respective positions. After the meeting, I sent a letter to the parties with written questions to which the parties timely responded. On May 15, 2019, I issued an informal oral recommendation for resolving the three issues. The parties conducted two additional meet and confer conferences and have informed me that they are still at an impasse. After a fair and full review of the parties’ positions, and in view of the specific needs of this case, I am now formally entering my recommendations for resolution of the disputed issues.

II. Discussion

a. Thread Suppression

 As proposed in the Protocol, the parties agree that “email threads are email communications that contain prior or lesser-included email communications.” The parties define a most inclusive email thread as “one that contains all of the prior or lesser-included emails and attachments, including each branch of the email thread.” Where the parties disagree is in the use of thread suppression

The Plaintiffs assert that a production of only the most inclusive email thread, as Defendants propose, would deprive them of relevant information and the metadata of each separate email communication. The Defendants assert that thread suppression would reduce the time required to review the emails by 50% to 82% and that threading leads to more consistent redacting and a  more complete presentation of email conversations. Notwithstanding their position, Plaintiffs have offered to accept thread suppression if the metadata of the lesser-included emails is produced as well.

I do not believe that all parties must always have identical functionality with all data. Rather, compromises are regularly made in functionality to facilitate the practical requirements of discovery and litigation. I agree with Defendants that email threading is an efficient laborsaving technique during document review. However, the issue before the court is document production, not document review. In any discovery, parties can agree (and in other cases – implicitly or explicitly – have agreed) to accept threaded-emails as a viable form of production. Here, the parties have not agreed to do so, and the case law favors the production of individual emails or metadata for individual emails.

The Defendants observation that tools such as dtSearch allow for great flexibility in the searching of in-text dates is noted. However, Plaintiffs have made a case for not merely being able to find individual dates when sought but being able to analyze them as fielded data. Added to this, the facts alleged in this case favor having access to individual email metadata.

The Court has already ruled that redactions for non-responsive documents will not be allowed and that trade-secret issues will be handled by confidentiality designations rather than redactions. This finding limits the number of non-privileged redactions in this case, and the associated burden of coordinating redactions.

“The Court has determined for several reasons that a party may redact or withhold responsive documents only where they are covered by attorney-client privilege or the work- product doctrine or contain sensitive personally identifying information.”

 (Doc. No. 938.)

Production of the most inclusive email thread, as defined by the parties in the Protocol, will allow for efficient review, will maximize the metadata for analysis, and will still provide for more complete “conversations” to be presented as exhibits. Production of the metadata for suppressed emails will allow for analysis of the timing, cadence, and frequency of party communications, which is obviously material given the allegations in this case.

Therefore, for this case and the facts alleged, and because Plaintiffs have offered to accept email threading as long as they also receive the metadata of lesser-included suppressed emails, I recommend that the ESI protocol adopt the language in Appendix A.

The metadata requirement for these non-privileged emails is restricted to only those emails actually collected and actually suppressed. Producing parties are not compelled to manually create metadata for non-captured, non-privileged emails. Further, I have spoken with the parties suggesting methods whereby this process can be automated.

b. Logging of Privileged Email Threads

Plaintiffs and Defendants have already agreed in the Protocol on the criteria for logging documents or ESI where privilege is asserted. This process includes, inter alia, the date of the document or ESI, the identity of senders, recipients, copies, and blind copies, and job titles, a description of the subject matter of the information contained in the document or ESI without revealing privileged or protected information, and the type of privilege asserted. The dispute here lies with threading and whether to log lesser-included emails. Plaintiffs want every email logged; Defendants want to log only the most inclusive email.

Plaintiffs argue that it would be difficult to assess the validity of the privilege asserted if only a most inclusive email if logged and that every thread would have to be challenged. Defendants argue that the law and federal rules do not require the logging of every privileged email when the most inclusive privileged email is logged. In the cases cited by Defendants, however, it appears that emails in a chain were not required to be logged as privileged where those emails were otherwise separately produced or logged as privileged. This assumes that lesser-included emails are otherwise produced. That is not the situation, here.

Again, I find that the law favors the consideration of each email as a separate communication and requires the production of sufficient information to assess the privilege asserted. Plaintiffs have offered to accept a single log entry plus the redacted image of the threaded email. I expect that this resolution will provide Plaintiffs with less detail, and less utility, than the production of individually coded metadata for each part of the chain, as I have recommended for nonprivileged emails. Notwithstanding, this will allow the producing party to reduce the number of email conversations that need to be redacted, reduce the risk of inconsistent redactions, while still providing the requesting party sufficient information to assess and, if necessary, challenge the privilege designation. Therefore, this is a compromise between burden and utility. Based on that balance, it is my recommendation that email threads with privilege assertions be produced as a redacted document, or with individual lesser-included emails individually logged on the privilege log.

Unlike non-privileged emails, the requirement to log metadata, should the producing party choose to log rather than redact, would require the party to log each lesser-included email, regardless of whether it was actually collected.

c. Production Format Field: CustodianOtherDirectory

As it relates to production format, the parties have agreed that a producing party may deduplicate ESI horizontally (globally) across the population of records, if the producing party discloses to the receiving and requesting party that it has done so. The parties also agree that all custodians who were in possession of a deduplicated document must be identified in the AllCustodian field. As stated in the Protocol, to ensure accuracy this field must be captured by an automated process and cannot be populated manually. In the event of a rolling production, the producing party shall provide an overlay load file with updated fields. The dispute lies in that Plaintiffs believe that the automated population of the CustodianOtherDirectory field is also important; Defendants argue that this process is unduly burdensome.

The CustodianOtherDirectory field is the path by which an electronic document is found and is comparable to the title of the folder in which a paper document is found. The Defendants have conceded that this information is collected and available. I recognize that an overlay file is: 1) already a necessity due to rolling productions and the needs of other production fields; 2) should not, in my experience, require a burdensome amount of time to create; and 3) any time required will largely be machine time, not personnel time. Plaintiffs have been made aware that production of this field may not result in the same ordering of information as the content of the AllCustodian field. Also, Plaintiffs have indicated that an additional delay in receiving an overlay file, to accommodate the aggregation of this field, does not outweigh the benefit of receiving this information in this case.

For these reasons, it is my recommendation that the parties produce the “CustodianOtherDirectory” field. To the extent this field is produced in an overlay, the producing party shall track how long it takes to run the scripts and the number of records considered per overlay. If this process exceeds twelve (12) hours, then the producing party may revisit this issue but shall not delay production of documents and the other ESI protocol fields.

III. Recommendations

To conclude, I recommend that the order reflect these three points:

1) thread suppression be allowed, when accompanied by metadata for any lesser-included threads that are not produced due to thread suppression,

2) email threads with privilege assertions be produced as a redacted document, or with individual lesser-included emails individually logged on the privilege log,

3) the parties produce the “CustodianOtherDirectory” field, and 4) that the ESI Protocol be resolved with the language included in Appendix A to this report and recommendation (emphasis added).

Respectfully submitted the 28th of June, 2019,

Daniel L. Regard,
Special Discovery Master for ESI

Appendix A: Language for the ESI Protocol

4.2 b) Production Format, De-Duplication, Horizontal Deduplication

A Producing Party may de-duplicate ESI horizontally (globally) across the population of records, if the Producing Party discloses to the Receiving Party and the Requesting Party that it has deduplicated horizontally, and provided further that: (a) an email that includes content in the BCC or other blind copy field shall not be treated as a duplicate of an email that does not include content in the BCC or other blind copy field, even if all remaining content in the email is identical; and (b) all Agreed Custodians who were in possession of a de-duplicated Document, and the directory structure where the Agreed Custodian stored the de-duplicated Document, must be identified in the AllCustodian and CustodianOtherDirectory metadata fields specified in Exhibit A.

To ensure accuracy, the AllCustodian and CustodianOtherDirectory Metadata fields must be captured by an automated process and cannot be populated using a manual process. The aforementioned Metadata must be produced to the extent it exists. In the event of a rolling production of Documents or ESI items, the Producing Party shall provide an overlay load file with updated AllCustodian and CustodianOtherDirectory Metadata fields along with each production. The Metadata overlay may contain a full refresh of data for the AllCustodian and CustodianOtherDirectory fields or be a supplement to the information previously provided for the fields. At the time of production, the Producing Party shall identify the overlay as a full refresh or a supplement. A Metadata overlay file shall be either a full refresh overlay or a supplemental overlay. 

4.3 Production Format, E-mail Thread Suppression 

Email threads are email communications that contain prior or lesser-included email communications. A most inclusive email thread is one that contains all of the prior or lesserincluded emails and attachments, including each branch of the email thread. A Producing Party may use e-mail thread suppression to exclude email from production, provided however, that an email that includes an attachment or content in the BCC or other blind copy field shall not be treated as a lesser-included version of an email that does not include the attachment or content, even if all remaining content in the email is identical. To the extent that a Producing Party uses e-mail thread suppression to exclude email from production, the Producing Party shall produce the metadata for that suppressed email. 

11.3 Assertions of Privilege 

For email threads, the Producing Party shall log an entry for each lesser-included email in the thread, or the Producing Party shall log a single entry for the entire thread and produce a redacted version of the threaded email.