A Peep into our Mail BagDigging into the digital mail bag (there’s a skeuomorph for you), I received a series of thoughtful questions from a reader ready to dip his toes into the bracing waters of native production but harboring some of the same nagging concerns others raise when they ponder how to integrate native production into workflows born of legacy paper processes.

Here were the questions:

What is the exact difference between native and near-native?  My big concern with producing natively is from what I’v’e read about the risks related to metadata/privilege and how to go about using native data at depositions and in court.  Are those concerns that can be dealt with simply?  Finally, how do you go about producing natively?  I presume by uploading data to an ftp site for the parties to access?  Are there other ways?

I replied:

The difference between native and near-native is admittedly subtle; but, the distinction emerges when we inquire into “true” native forms.  For example, a company employing the Microsoft Exchange e-mail server application to manage corporate e-mail houses its e-mail collection in a file with the extension “EDB” (for Exchange DataBase).  The EDB holds everyone’s e-mail, calendars, contacts, etc.  for the entire e-mail domain.  No one is going to seek or produce that huge Exchange database just because it’s–strictly speaking–the “native” form of the data.  However, the contents of individual custodian’s accounts can be exported out from the EDB as, e.g., a PST container file or MSG single message files.  These are deemed “near native” because they retain most of the essential, functional characteristics of the “true” native form, but they are not the actual form in which the native application stores and uses the data.

Near native forms can typically be imported back into the native application because the structure of the data (a/k/a the “fielding” of the data) can be easily mapped back and forth between the native and near-native iterations.  This is in contrast to imaged forms which do not preserve fielding or functionality (although load files are often supplied with imaged productions in a feeble effort to restore a diminished level of functionality).

If I had to define near-native, I would suggest that it’s a form that, though not the same as the native format employed by the native application, is sufficiently similar in its content and structure to permit it to be brought back into the native application with little or no loss of content or utility.  I wrote about this further here in the context of e-mail production.

Turning to risks associated with metadata in native content, I’ve written extensively about same and remain dumbstruck that so many believe it is appropriate to deal with substantive content–whether privileged or not–by simply destroying it in lieu of reviewing it.  Yet, that is precisely what goes on today in most imaged productions.  For example, if a supervisor and a subordinate collaborate on a relevant Word document, the supervisor’s comments visible in Tracked Changes are substantive communications between witnesses that may be powerful, probative, non-privileged evidence. Certainly the communications would be fair game for discovery had they been made in an e-mail; so, how is communicating via embedded comments different than communicating via e-mail? Such comments and other embedded content and data are frequently and insidiously stripped away without review in imaged productions, making it appear to lawyer reviewers as if no such communications ever occurred.

Some lawyers have found their bliss in ignoring such evidence and do not want to be troubled to deal with it.  Other lawyers are blissfully unaware of what’s missing. We need to expose the shame in both.  My sense is we do not enjoy the right to pretend substantive content doesn’t exist by simply obliterating it before review. It’s not much different than erasing margin notes on paper documents before photocopying them.  When you look at the issue that way, the practice is indefensible despite its ubiquity.

A modern review platform is fully capable of searching and displaying the document comments, tracked changes and the like.  Moreover, the incidence of collaborative commentary, tracked changes, speaker notes and other content currently stripped out tends to be small despite its (often) greater relevance; accordingly, such content poses little added burden on counsel.  We just have to come to grips with the fact that our client use such collaborative features, and we cannot blithely assume otherwise.

[I should explain myself here in terms of characterizing comments and tracked changes as having ‘greater relevance’ than being just more ‘stuff’ to review. Such content tends to reflect one person voicing concerns and seeking to influence or alter the actions or expression of another.  It might just be correcting a spelling or grammatical error; but, it’s also where one finds manifestations of intent to conceal information, or of conspiracy, strategy, intent, fraud and state of mind. These shed light on awareness, motivation and mens rea.  It’s the place where people tell each-other, in so many words, “don’t do that!“]

One huge mistake lawyers make is assuming that producing in native entails reviewing in native.  It does not.  When someone produces an Excel or Word file, the recipient need not–and should not–use Excel or Word to undertake review of same.  Competent counsel wants–I would say competent counsel needs–the utility and completeness of native or near native production; but competent counsel does not want to alter the evidence by using native applications for review.  Native applications (Word, PowerPoint, Excel, etc.) are not designed to protect the integrity of their files as evidence, nor to support the workflow of review, tagging and the other common features of a well-crafted review tool.  The proper way to undertake litigation review of native ESI is by use of a tool designed for review of native ESI, not the native applications themselves.  This proves hard for lawyers to grasp, although I’m uncertain why that should be so.

I admire the question about use of native ESI in court as it’s a very wise and practical one.  It also goes to the issue of Bates numbering.  For the most part, we use only the tiniest sliver of information produced in discovery at proceedings–maybe as little as 1% or less in many cases.  Why pay princely sums to convert *everything* produced into less-utile, paper-like forms when only a handful of the items produced will ever require conversion?  My suggestion is that, when you need alternate paper-like forms for depositions, motions and trial necessitating printing same out, just do it.  AT THAT TIME, you emboss the Bates/control number and page number on the (now changed) evidence for ease in making your record, then furnish copies of the newly paginated item to counsel in attendance.  It’s easy, familiar and it saves a TON of money.

Printouts and ESI are not the same thing.  The notion that they are “the same” is a vestige from our paper days.  Native files naturally share some characteristics of the objects (images or printouts) generated from the native, but offer very different capabilities in terms of searchability, functionality and completeness.

As to medium of production, you can use whatever medium you now use to tender images and load files: CDs, DVD, thumb drives, hard drives, FTP, even e-mail for small collections.  You will retain hash values of what you supply so as to always be able to verify same.  It’s simpler and cheaper than its paper forebears, to be sure.

What I was trying to convey in my post called “Its the Parties’ Data, Stupid” is that lawyers need to appreciate that the forms in which we often see client data (e.g., TIFF images) are artificially created just for us because we are so hampered in our ability to deal with the electronic forms of information our clients take for granted. We’ve come to confuse the dumbed-down stuff we review with the real evidence; but, in fact, the two are getting farther and farther apart.  Certainly, many lawyers don’t want things to change–change is disruptive and challenging–but neither can we go on as we have.  It’s simply malpractice and a great disservice to the notions of fundamental justice we are sworn to support.  Knowing how to deal with modern evidence and pursue cost-effective discovery shouldn’t be deemed an optional measure of professional competence.

Can you imagine any other modern setting where people elect to use electronic information by (in essence) printing every single thing out?  Imagine surfing the net with no screen–just a printer.  How awful–how wasteful–would that be?

We must endeavor to migrate the forms of production upstream from depleted images and load files to functional native and near native forms retaining the content and structure that supports migration into any form.  Native and near native production supports maximum flexibility.  You can convert to virtually any form that suits you–TIFFs and load files, if that’s what you want, or to forms suited to the best tools available today AND tomorrow, extracting maximum insight.

So, let’s see:  Costs less.  Check.  Works better.  Check.  Affords maximum flexibility. Check.  No wonder so many shy away!  Cheaper access to justice?  Nuts!  Next thing you know gals will want equal pay for equal work!