A Critique of the Delaware District Court's Revised Default eDiscovery Standard

As many of you are likely aware, the Delaware District Court revised its Default Standard for Discovery back in December. Several sources walked readers through the new provisions and speculated about the practical impacts of the new Default Standard. I opted to wait until working under the new Default Standard before offering commentary. Now that I have had the opportunity to use the new Standard in real cases, I'm ready to offer a practical critique.

The new Default Standard is a real leap forward from its predecessor and an excellent guide for litigants. Whereas the old Default Standard was basic, a bit scattershot, and meant to be a punishment to parties who failed to cooperate, the new Default Standard is a gift wrapped eDiscovery plan. (It's my understanding that DuPont's Global eDiscovery Director, Vince Catanzaro, was a driving force behind development of these new guidelines. Well done Vince!) To date, I have used the new Standard in several cases as the basis for agreements for conducting eDiscovery. Among it's best features are:

  • A focus on early party Meet & Confers regarding eDiscovery, including early consideration of Proportionality;
  • Schedule A of the new Standard lists data types and sources that are excluded from preservation absent a good cause showing;
  • A list of metadata fields that parties must exchange, no other fields are required;
  • During search term discussions, receiving parties may request no more than 10 additional search terms;
  • Seeks enforcement of the FRCP 26(f) Meet & Confer requirement to discuss eDiscovery and the timing of the same;
  • Protection of litigation holds and other preservation efforts from discovery; and
  • On-site inspection of the producing party's information systems is barred absent a good cause showing.

However, the new Standard is not without it's flaws. Although none of it's flaws are major, there are a few items that I think are unclear in the new Standard. I will address them in the order in which they appear in the new Standard, citing the section, so you can play along at home.

The first oddity, while not an actual flaw per se, merits mentioning because of its irony: the document appears to be scanned paper. Odd.

To Preserve or Not To Preserve

The first possible flaw is that the language of section 1.c.(i) seems to contradict or at least conflict with Schedule A #5. I'll explain.

Schedule A of the new Standard lists data types and sources that are excluded from preservation absent a good cause showing. Schedule A #5 identifies "Back-up data that are substantially duplicative of data that are more accessible elsewhere." The inclusion of the word "substantially" here means to me that the Court recognizes and accepts that *some* relatively small amount of non-duplicative data may be lost. So good cause to preserve a backup source would require showing that a backup has a unacceptably large amount of non-duplicative data. Just showing one document, or even a few, would likely not be good cause to force preservation. This is pragmatic and enlightened, and I like it (and I'm sure the Court is relieved to know that I approve).

However Section 1.c.(i) concerns the scope of discoverable information and says:

Absent a showing of good cause by the requesting party, the parties shall not be required to modify, on a going-forward basis, the procedures used by them in the ordinary course of business to back up and archive data; provided, however, that the parties shall preserve the non-duplicative discoverable information currently in their possession, custody or control.

To me, the first phrase in this section says that parties don't need to change their regular backup routines, including the regular destruction of backups. In other words, just like Schedule A #5, there's no need to preserve backups. Good.

Not so fast. The second phrase in section 1.c.(i) says that parties may only continue executing their regular backup routines, including the regular destruction of backups, if there is no unique data in a backup. There's unique data in most backups, so reading the second phrase literally seems to negate the first part of section 1.c.(i).

That is, section 1.c.(i) really says that parties may continue executing their regular backup routines, including the regular destruction of backups, if, and only if, the backups they intend to destroy have no unique data. None. Zero. This could cause parties to keep all backups for fear that any of them contain even one unique item. Not only is that a bad rule, it directly contradicts Schedule A #5's exclusion of backups from preservation.

I have no doubt that causing parties to keep all backups was not the Court's intention, and this is merely a drafting error. Nevertheless, it's potentially problematic, and I hope it will be corrected. I offer the following language as a possible alternative:

Neither party shall be required to modify, on a going-forward basis, the procedures used by them in the ordinary course of business to back up and archive data, unless those procedures may be reasonably expected to destroy potentially relevant data that does not also exist on a more readily accessible source.

Translucence Anyone?

This isn't a flaw so much an issue with style.  Section 1.d.(iii) says:

Activities undertaken in compliance with the duty to preserve information are protected from disclosure and discovery.

While this is certainly a clear and welcome statement that preservation activities are protected, there are times when disclosing some of those activities is helpful. If a party discloses their preservation efforts and the opposing party will agree (in writing) that those efforts are reasonable, the disclosed preservation effort then become highly defensible.

Section 1.d.(iii) doesn't preclude such disclosure and discussion, but it doesn't encourage it either. I would have preferred the section said something like:

Although activities undertaken in compliance with the duty to preserve information are protected from disclosure and discovery, parties are encouraged to share this information in reasonable detail when appropriate in the interest of cooperation.

I'm not married to that language, but you get the idea. Like I said, this isn't a flaw, just a style preference.

String Theory

Section 5.b. does a lot of good things, but I believe it could use some clarification. Specifically, it says:

Absent a showing of good cause, a requesting party may request no more than 10 additional terms to be used in connection with the electronic search.

What counts as a search term? Quite often, we use search strings (e.g. "too much" w/3 noise) of varying complexity, because they yield more tailored results and smaller data sets than individual terms (e.g. "noise"). So, I may have several search strings like:

  • Smith AND [misappropriat* OR stole OR steal* OR (customer w/3 list) OR (client w/3 list) OR fire OR terminat* OR discipline* OR suspend* OR resign* OR unemploy*] between 1/1/08-1/1/10
  • (Kennedy OR Jones OR Adams) AND (fire OR terminat* OR discipline* OR suspend*) between 9/15/09-10/15/09
  • Smith AND [perform! OR theft! OR (client w/7 contact)] between 10/1/08-11/1/10

What exactly can the receiving party request? It seems clear to me they can request that individual words be added to a string with each word counting against the 10. That is, using the above strings, the receiving party can request the addition of "account" to the final string so it reads:

Smith AND [account OR perform! OR theft! OR (client w/7 contact)] between 10/1/08-11/1/10.

The requesting party can do that 9 more times.

But what if the receiving party requests the addition of "account manager" instead? Is that one term or two? What if, in addition to the strings above, they requested we also run: "(Williams OR Martin OR Wilson) AND (captur* OR escap* OR dwindl*) between 6/15/09-8/15/09?" Is that 6 terms? I think so, but, to avoid party confusion and unnecessary court intervention, this could be clarified.

Going Native

Section 5.d. says:

The only files that should be produced in native format are files not easily converted to image format, such as Excel and Access files.

I see two problems here. The first is a minor drafting error. For accuracy, "Excel" should be changed to "spreadsheets" (I would even add "and similar files like those with a .csv extension"). Certainly, Excel spreadsheets are the most common spreadsheets--and perhaps Excel has become synonymous with spreadsheets the way Qtips now means all cotton swabs--but there are many of us who use non-Excel spreadsheets. This is an easy fix.

The other problem is two-fold. First, like the Excel issue, "Access" should be changed to "databases." Again, there are many other types of databases besides Access. In fact, I would wager SQL (pronounced sequel) databases are the most common right now. This is also and easy fix, but there's a much bigger problem here.

The second problem is that production of entire databases is not a very good way to handle databases in eDiscovery. In fact, it's a bad way to handle them.

The Sedona Conference® Database Principles Addressing the Preservation and Production of Databases and Database Information in Civil Litigation (April 2011) explains that the best way to handle databases in eDiscovery is to generate relevant reports for production. This requires the producing party to determine the fields available in a given database, disclose the fields to the receiving party, and negotiate relevant reports.

There's more to it than that, but that's the basic idea: database production is based on reports not exchanging entire databases. This process is very similar to search term negotiation and development, except the discussion is about database fields. I would hope this portion of the new Standard can be revised quickly, because I think it could prove problematic.

Metadata, I Knew You Well

Section 5.e. lists the metadata fields parties must provide. Among the fields listed are Conversation Index, Control Number Begin, and Control Number End.

Conversation Index. As I understand it, this is a field created by eDiscovery software that identifies and groups email threads, which is useful during review. Not all software does this, so not everyone will have a Conversation Index field to produce. Even when a party does have this field, it exists for their own use during review and is not something typically produced, if ever. Moreover, even if a party were to produce this field of information, most, if not all, review software would be unable to utilize the information. This field should be removed from the list.

Control Numbers. These are typically numbers assigned to documents for internal use and are never disclosed. I think what was intended here was Bates Begin and Bates End. These are arguably the two most important fields parties must exchange, but they do not currently appear on the list.

Title. This is a commonly exchanged field indicating the title given to an office document. I would have included it on the list.

Missing in Action

As terrific as the exclusions in Schedule A are, they do not address custodians' personal data, SMS text messages, or social media. Maybe the Court doesn't want these categories of data excluded by default, but they seem to fit in nicely with the other categories on that list. Either way, some guidance on handling these types of data would have been appreciated, especially considering how frightened some people seem to be about social media.

Drum Roll…

If you like the new Default Standard as much as I do, you will want to use it as the basis for a form eDiscovery agreement for use in Delaware District Court and any other court. After all, why reinvent the wheel? But, as pointed out above, the new Standard is not perfect. The workaround for that is to pull the text of the new Standard into a form agreement and correcting the errors discussed above. After that, all you will need to do is make changes warranted by the specific circumstances of a case and you're done. Pre-cooked eDiscovery Plan.