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 →

“American laws and American policy view the content of communications as the most private and the most valuable, but that is backwards today,” said Marc Rotenberg, the executive director of the Electronic Privacy Information Center, a Washington group. “The information associated with communications today is often more significant than the communications itself, and the people who do the data mining know that.”  
How the U.S. Uses Technology to Mine More Data More Quickly, New York Times, June 8, 2013

Marc Rotenberg was commenting on the recent revelation that the U.S. National Security Agency gathers a staggering volume of information about domestic and international telephone calls.  When he states, “The information associated with communications today is often more significant than the communications itself…,” he doesn’t expressly label that “more significant” information as being “metadata,” but that’s what it is.

Rotenberg’s right: metadata matters. Continue reading →

I did an ILTA webcast this morning called “Going Native.” Steven Clark ably moderated the panel including Denise Talbert and Maureen Holland.  D4 sponsored.  Going Native did not mean we spoke in loincloths (although I can really only account for my own attire).  We addressed the pros and cons of producing ESI in native and near native forms versus conversion from native forms to TIFF images and load files.  I expected agressive pushback as I sang the praises (Just! Speedy! Inexpensive!) of native productions; but, steeled for debate, I was instead treated to fine dialog.  No one trotted out the usual hackneyed objections to native productions.  Advantages and disadvantages were thoughtfully addressed and everyone proved open to flexibility in forms of productions when to do so serves to meet a genuine need or solve a problem.

When polled, roughly half of those attending stated that they weren’t making production in native and near-native forms simply because the requesting parties hadn’t sought same.  Around 16% said they resisted native production out of concern that native productions were harder to track.  My sense is that the attendees were open–even eager–to embrace native production.  I wasn’t surprised by this because there are few audiences for e-discovery education as sophisticated and rational as ILTA audiences.  ILTA members tend to be hands on with ESI, affording them a better appreciation of the downsides of image and load file productions.  They’re typically the ones tasked with cleaning up the messes caused by malformed load files and TIFF creation errors.

That 16% missing out on the advantages of native productions out of concern that native files aren’t Bates stamped on each page distresses me because I’m sure they correspond to a much larger percentage of lawyers who can’t conceive of litigating without Bates numbers (and protective legends) on every page. It seems a lot of people don’t realize that you don’t have to give up Bates numbers and protective legends when you make native productions.  If you approach native productions the right way, the Bates numbers will still be there when you need them.  I’ll explain how that works, but first please indulge me in a little mental exercise. Continue reading →