I speak with a lot of judges about e-discovery and digital evidence.  I’ve taught at Federal Judicial Center programs from coast-to-coast and addressed confabs of judges in various states. Some of these presentations have turned into annual pilgrimages.  Have PowerPoint.  Will travel.

It’s a privilege to address judges because, among their own, judges are more cordial, relaxed and candid than in their courtrooms.  But, it’s also a responsibility and a challenge.  In the state systems, I can often be a judge’s first exposure to e-discovery.

Lawyers want the quick course in e-discovery.  They expect to glean ESI skills in minutes, before they glaze over with the talk of metadata and forms of production. Lawyers seek the canned checklist or scripted list of questions, and little care if they understand what the check boxes mean or what the follow up question should be.

It drives me bonkers.

Judges want the quicker course in e-discovery.  They’re not driven to win the case. They’re not worried about losing a client or looking bad to the partners. They know that discovery rulings are discretionary and rarely prompt findings of reversible error.  Federal District Judges get to keep their jobs for life. Apart from hereditary monarchs, who else has that sort of job security?

Judges have hardly any incentive to learn something new, save one: They really want to make the right decisions.

But despite such purity of purpose, there are many reasons why e-discovery can be more challenging for the bench than for practicing attorneys, viz.:

• Judges tend to be more senior, with the consequence that most had little hands-on experience with electronically stored information (ESI) in their own law practices;
• Most lawyers are at sea with the technology, so less adept at framing ESI issues, making a record and educating courts;
• The common practice to “split the baby” to achieve a just result rarely prompts good outcomes in e-discovery.

Recently, a judge asked me to pull together tips for jurists dealing with e-discovery; a list slated to be part of a presentation to a statewide judicial conference later this year. Responding to that request became the topic of my upcoming column in the October issue of Law Technology News, where I offer ten tips for judges who want to get e-discovery right.  Some are merely aspirational.  Some are pretty specific.  Here’s  a preview: Continue reading →

I got a call from a lawyer I don’t know on Sunday evening.  He reported that he’d received production of ESI from a financial institution and spent the weekend going through it.  He’d found TIFF images of the pages of electronic documents, but couldn’t search them.  He also found a lot of “Notepad documents.”  He’d sought native production, so thought it odd that they produced so many pictures of documents and plain text files.

As it’s unlikely a bank would rely on Windows Notepad as its word processor, I probed further and learned that that the production included folders of TIFF images, folders of .TXT files (those “Notepad documents”) and folders of files with odd extensions like .DAT and .OPT.  My caller didn’t know what to do with these.

By now, you’ve doubtlessly figured out that my caller received an imaged production from an opponent who blew off his demand for native forms and simply printed to electronic paper.  The producing party expected the requesting party to buy or own an old-fashioned review tool capable of cobbling together page images with extracted text and metadata in load files.  Without such a tool, the production would be wholly unsearchable and largely unusable.  When my caller protests, the other side will tell him how all those other files represent the very great expense and trouble they’ve gone to in order to make the page images searchable, as if furnishing load files to add crude searchability to page images of inherently searchable electronic documents constitutes some great favor.

It brings to mind that classic Texas comeback, “Don’t piss in my boot and tell me it’s raining.”

It also reminds me that not everyone knows about load files, those unsung digital sherpas tasked to tote metadata and searchable text otherwise lost when ESI is converted to TIFF images.  Grasping the fundamentals of load files is important to fashioning a workable electronic production protocol, whether you’re dealing with TIFF images, native file formats or a mix of the two.  I’ve been wanting to write about load files for a long time, but avoided it because I just hate the damn things!  So, this post is a load (file) off my mind. Continue reading →

Recently, I’ve weighed in on disputes where the parties were fighting over whether the e-mail production was sufficiently “native” to comply with the court’s orders to produce natively.  In one matter, the question was whether Gmail could be produced in a native format, and in another, the parties were at odds about what forms are native to Microsoft Exchange e-mail.  In each instance, I saw two answers; the technically correct one and the helpful one. 

I am a vocal proponent of native production for e-discovery.  Native is complete.  Native is functional.  Native is inherently searchable.  Native costs less.  I’ve explored these advantages in other writings and will spare you that here.  But when I speak of “native” production in the context of databases, I am using a generic catchall term to describe electronic forms with superior functionality and completeness, notwithstanding the common need in e-discovery to produce less than all of a collection of ESI.

It’s a Database

When we deal with e-mail in e-discovery, we are usually dealing with database content.  Microsoft Exchange, an e-mail server application, is a database.  Microsoft Outlook, an e-mail client application, is a database.  Gmail, a SaaS webmail application, is a database.  Lotus Domino, Lotus Notes, Yahoo! Mail, Hotmail and Novell GroupWise—they’re all databases.  It’s important to understand this at the outset because if you think of e-mail as a collection of discrete objects (like paper letters in a manila folder), you’re going to have trouble understanding why defining the “native” form of production for e-mail isn’t as simple as many imagine.  Continue reading →

In any plaintiff’s case, the claimant is Exhibit A.  A claimant must be credible because, where the number of lies a jury allows a defendant varies from case to case; the person suing for money gets none.  One reason I liked trying wrongful death cases was that the victim couldn’t testify.

A common way to prove a claimant isn’t credible is by proving the claimant tells different stories about matters made the basis of the suit.  Such “prior inconsistent statements” are excluded from the rule against using hearsay testimony, not just as an exception to the rule but by being defined as “not hearsay.”[1]  So, if a defendant can lay hands on such statements, the statements are coming into evidence and may really hurt.

Nowadays, many prior inconsistent statements are found on social networking sites like Facebook, LinkedIn and Twitter.  Facebook posts and tweets with tales of actions and attitudes at odds with claims in court are splendid fodder for impeachment.  Even a Facebook photo of a claimant with a smile may serve as ammo for impeachment when mental anguish damages are sought. Continue reading →

I’ve been skeptical of predictive coding for years, even before I wrote my first column on it back in 2005.  Like most, I was reluctant to accept that a lifeless mass of chips and wires could replicate the deep insight, the nuanced understanding, the sheer freaking brilliance that my massive lawyer brain brings to discovery.  Wasn’t I the guy who could pull down that one dusty box in a cavernous records repository and find the smoking gun everyone else overlooked?  Wasn’t it my rarefied ability to discern the meaning lurking beneath the bare words that helped win all those verdicts? 

Well, no, not really.  But, I still didn’t trust software to make the sort of fine distinctions I thought assessing relevance required. Continue reading →