eDiscovery Daily Blog

No Bates, No Problem for Native Files: eDiscovery Throwback Thursdays

If you read my blog post on Tuesday, you saw my coverage of Craig Ball’s blog post regarding whether we’ve “lost the war” on eDiscovery.  Craig particularly lamented the lack of focus on practical eDiscovery skills, especially in the eDiscovery conferences we attend, where they have moved on to “anti-discovery topics”, such as proportionality, privacy, General Data Protection Regulation (GDPR) and cybersecurity.  Certainly, that sentiment probably extends to publications as well, as we have covered a lot of those “anti-discovery” topics extensively.  But we used to cover a lot more of the practical eDiscovery best practices in the early years of the blog.  And, that got me thinking that maybe we should revisit some of those topics.

So, I’m starting a new series – Throwback Thursdays – here on the blog, where we will do just that – revisit some of the eDiscovery best practice posts we have covered over the years and discuss whether any of those recommended best practices have changed since we originally covered them.  That’s not a new idea: Craig did that on his blog in the past and we have re-played some of our own best practice posts (with some updates) when the topic came up again in our dealing with our clients.  We even had a previous “Throwback Thursday” series on this blog that my former colleague Jane Gennarelli wrote about the early days of technology in litigation support.  Nonetheless, we will start running this series on Thursdays (most of them, anyway) for a while as many of these topics were covered by this blog when we had a lot less readers than we do now.  It’s new if you haven’t heard it, right?  :o)

Our first Throwback Thursday post is one we published back in March 2011 – when the eDiscovery Daily blog was less than six months old.  It’s one that made me laugh when I read it – not because the advice is any less sound, but because I stated that is has become “commonplace” for parties to agree (and courts to accept) a file-level ‘Bates’ or Unique Production Identifier (UPI) where each file is named with a prefix and a sequential number.

Well, I might have overstated that a bit!

Especially when you consider this case from less than a year ago where a Kansas Magistrate Judge stated that “there is no dispute that documents in TIFF format are easier to work with and enable depositions and court proceedings to run more smoothly”.  It seems like many attorneys and some courts still have to learn that you can produce in native format and still support the idea of presenting in image format.

So, it was probably accurate when I stated that “it seems to ‘upset the legal apple cart’ when attorneys have to contemplate applying Bates numbers to native files.”  No kidding!  As I noted back then, “many native file types are not stored in a typical paginated, document-oriented format, [so] it is difficult to impossible to determine the number of pages for each file.  Because attorneys are so used to having a Bates stamp on each page of a document, many are still known to produce (and request production) in an image format, adding costs unnecessarily.  That would be like printing out every email in your Inbox before reading them.”

Back then, I talked about accepting a file-level Bates number where each file is named with a prefix and a sequential number (just like a Bates number, only they’re not stamped in the file, but used as the file name).  These productions are usually accompanied by a data file, containing metadata for loading into a review tool, which includes the original file name and path of each file being produced.  I also noted that “[i]f there’s a concern about referencing individual page numbers at deposition or trial, any files used as exhibits can still be converted to image (or printed) and a number applied.  You could simply use the UPI as the prefix, followed by a sequential number, so page 3 of the 11th file in the production could be stamped like this: PROD000011-00003.  This enables you to uniquely identify each native file, and still correlate the native file with pages when printed.”

Makes sense, right?  If so, why are we still debating this over eight years later?  Regardless, here’s the post we originally published back in March 2011.

So, what do you think?  Are your productions routinely in native format?   If not, why not?  Please share any comments you might have or if you’d like to know more about a particular topic.

Sponsor: This blog is sponsored by CloudNine, which is a data and legal discovery technology company with proven expertise in simplifying and automating the discovery of data for audits, investigations, and litigation. Used by legal and business customers worldwide including more than 50 of the top 250 Am Law firms and many of the world’s leading corporations, CloudNine’s eDiscovery automation software and services help customers gain insight and intelligence on electronic data.

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by CloudNine. eDiscovery Daily is made available by CloudNine solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Daily should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.

print