e-discovery 2.0

Anyone reading today’s announcement from Kazeon could be forgiven for doing a double-take: did someone misplace the decimal point? Kazeon claims that it can perform “processing of ESI in preparation for eDiscovery matters as low as $4.30 per Gigabyte.” Assuming that’s not simply a typo, it begs an obvious question: If Kazeon really can process information at a tiny fraction of what e-discovery service providers are charging, how come every e-discovery service provider isn’t going out of business? Why wouldn’t everyone take this incredibly good deal?

The answer (in press releases, as in politics) lies in definitions. Exactly what sort of processing would you be getting for your four dollars and change?

You’ll have to ask Kazeon to get the answer to that one, but give a venti latte to a bleary-eyed e-discovery service provider who’s just pulled an all-nighter preparing for a meet-and-confer, and they’ll tell you all about the nuances, complexities, and risks inherent in e-discovery processing that may be difficult for enterprise search/information lifecycle management vendors to grasp. Quite likely, they will refer you to EDRM’s processing node overview, which outlines the basic goals of robust processing:

• Capture and preserve the body of electronic documents;
• Associate document collections with particular users (custodians);
• Capture and preserving the metadata associated with the electronic files within the collections;
• Establish the parent-child relationship between the various source data files;
• Automate the identification and elimination of redundant, duplicate data with the given dataset;
• Provide a means to programmatically suppress material that is not relevant to the review based on criteria such as keywords, date ranges or other available metadata;
• Unprotect and reveal information within files; and
• Accomplish all of these goals in a manner that is both defensible with respect to clients’ legal obligations and appropriately cost-effective and expedient in the context of the matter.

And that’s just the high-level overview. After the caffeine from the latte starts to kick in, they’ll tell you it’s also absolutely critical to:

• Provide statistical count tie-outs that reconcile every incoming email, loose file, and attachment with the processed document set
• Automatically scan critical large container files (such as PSTs) for errors and problems prior to processing
• Automatically perform custodian mapping to track ownership of all documents
• Maintain detailed reports on every anomaly encountered during processing, down to the individual email, loose file, and attachment
• Automatically handle common metadata anomalies (with logging) so that the maximum number of documents are made available for review
• Provide robust and thorough handling for container files regardless of container format
• Support non-email content types such as contacts, calendar entries, tasks, and notes
• Robustly handle embedded objects
• Provide full visibility into exceptions encountered during processing, along with an integrated exception handling process to allow repaired/decrypted data to be easily added back into the document set

All that for under five bucks? That’s quite a deal! But remember, if you drive by your corner gas station tomorrow morning and they’re advertising regular unleaded for 20 cents a gallon: It may be cheap, but it’s probably not gas you’re getting.

In a time before e-discovery, I toiled away alongside a partner at Chapin, Fleming and Winet – Larry Shea. While not reducing his legal sagacity to one pithy catch phrase, his “no ask-y, no get-y” line is nevertheless a truism I often ponder.⁽ⁱ⁾

As a green associate, fresh out of law school, I had a number of idealistic (read: naïve) assumptions about how litigators wrangled over discovery disputes. One day, while dealing with a particularly thorny electronic discovery problem, I came to Larry and told him what I thought we wanted and why we needed it in a specific format. I knew that the opposition wasn’t likely to grant our e-discovery request, partially because they’d surely intuit how badly we needed it. Larry simply responded with his truism and explained that if we didn’t express our wishes we’d (a) likely not get what we wanted and (b) would not have established our position if push came to shove with the judge.

Well, I just read a recent case (Autotech Techs. Ltd. P’ship v. Automationdirect.com, Inc., 2008 WL 902957 (N.D. Ill. Apr. 2, 2008)) and it showed me that no matter how evolved the legal discovery process has become, the basic “no ask-y, no get-y” notion still applies.

In Autotech, the issue surrounded the production of electronically stored information (ESI) per Fed.R.Civ.P. 34(b)(2)(E) which basically says that court documents must be produced as they are kept in the “usual course of business” or in a “reasonably usable form.” Significantly, section (iii) also states that a party need not produce the same ESI in more than one form.

Unfortunately, the requesting party (ADC) didn’t specify a form for the production of the document at issue, so “Autotech had the option of producing it in the form in which it was ordinarily maintained, or in a reasonably usable form.” Similarly, ADC did not specify that it wanted metadata as a part of the responsive document production. The court was not sympathetic to ADC’s requests: “It seems a little late to ask for metadata after documents responsive to a request have been produced in both paper and electronic format.” The court ultimately found that “ADC was the master of its production requests; it must be satisfied with what it asked for.”

In other words, “no ask-y, no get-y.”

Yes, this all seems so simple, but parties still are routinely stepping in this same pothole. Useful e-discovery best practices to avoid this predicament follow along these lines:

1. Determine what format of ESI production you’re going to require. This sometimes isn’t as easy as it sounds since there are a number of permutations of review environments, even for common platforms such as Concordance [s1]and Summation Work backwards with the attorney review team and their litigation support personnel to figure out what you’ll need and the type of “load files” that are required.
2. Determine if you’ll likely want metadata. In lieu of any specific guidance, it’s fair to assume you’ll want metadata for spreadsheets (to calculate formulas), in cases involving computer forensics and for matters involving granular document authenticity/chain of custody, to name a popular few. The challenge is that you may not know about some of these issues at the time of the early Meet and Confer conferences. This is particularly important since there is a “modest legal presumption in most cases that the producing party need not take special efforts to preserve or produce metadata.” Williams, 230 F.R.D. at 651 (quoting The Sedona Principles, Comment 12a). So, the opposition may be on pretty solid footing if they claim that they had no duty to keep the metadata if you don’t make your needs known early on.
3. Ask for what you want. Here, you’ll want to get specific, especially if you’re wisely carving out certain data types for different handling. Documenting your requests is a good practice too.
4. Prepare to substantiate your needs for #1 & #2. Courts aren’t very willing to entertain overly broad requests for metadata if there isn’t a showing of need. So, be prepared to be challenged and have a solid rationale for the e-discovery request.

⁽ⁱ⁾ His saying, “if ‘its’ and ‘buts’ were candy and nuts it would be Christmas all year long” is another great pearl, but I couldn’t find a good case law tie-in.