In the first three articles in this series, we focused on the ILC (identify, locate, collect) phase of discovery, as well as the process of what comes slightly before that phase in the form of preservation. Then we took a look at processing and review. So, what now? What happens to all of this data? Well, we put it all together and turn it over to the opposing side. Why? Because as the lovely and talented Marisa Tomei reminded Joe Pesci in the movie, "My Cousin Vinny":

Mona Lisa Vito: Don't you wanna know why Trotter gave you his files?

Vinny Gambini: I told you why already.

Mona Lisa Vito: He has to, by law, you're entitled. 

And that's why both sides of a litigated dispute have to produce files: because of the movie "My Cousin Vinny." (Probably there are other reasons, but we'll stick with that for now.) Let's talk about what it looks like to actually produce documents to the other side so that Trotter can have his hat handed to him by the noob from New York, shall we?

We'll separate this out into the key components, but prior to that let's look at a bird's-eye view. The production phase is an offshoot of your own internal processing and review phases. This time, however, we're making a second pass at the data that has already been placed into the database associated with your e-discovery platform. This pass is needed to make sure that only nonprivileged documents are sent out, that they are all Bates numbered, that the requested formatting specifications from the other side have been followed, and that redactions have been handled. Let's tackle these key components one at a time.

Key Components of a Production

• Format

In order for the other side to be able to review what you've produced, they'll need to have the documents placed into a review system on their end. As mentioned above, this second pass at the documents is very similar to the review that you went through on your end). This will involve what's referred to in the industry as a "load file." If you recall in the ILC phase, we are collecting structured and unstructured data. We talked about the difference between those in Article 3—processing and review. Once everything's in "the funnel" (as referenced in processing and review) and reviewed, the documents marked responsive have to be exported back out for the other side to review them. The load file is a structured set of instructions for the database that opposing counsel will use to bring the production into their own review system. This file tells the document review platform how the data will go nicely into the database. You can think of it this way, that a load file gives a structured listing of all the files that are part of the production, an image of the document in the form of a .tif file, a text file (.txt) for each document that contains, you guessed it, the text portion of all of the documents being produced. What the opposing counsel's e-discovery team will do is bring the load file into their review platform, and it will show that platform where all the text files are that need to be reviewed.

The load file must be in the format specified by the other side, as part of a "spec sheet." The spec sheet is typically something that comes out of the meet and confer stage of litigation, aka 26(f) meeting, and needs to be followed in order to ensure a defensible e-discovery process. There are many types of e-discovery review software, and when the other side tells you which type they're using, you'll need to produce a load file in the format it can receive.

Also listed on the spec sheet will be a list of metadata fields the opposing side has requested. There are standard fields that are almost always included (email from, email to, date modified, date created, hash value). But there are other less obvious fields that provide extra information, such as whether or not an email was read. That is a flagged field that's part of the metadata and can be very useful in disputing testimony about whether or not an email that was sent by one party was actually viewed and read by another.

From a formatting perspective, each document produced must have a Bates number added to it. This is something that the e-discovery software does as it prepares the production. It is important to quality check Bates numbers before sending a production out, especially when you have done multiple productions. The numbers need to be consistently ordered, with no missing ranges and no overlaps. Finally, following the aforementioned spec sheet, confirm if the other side has requested native files. If native files are requested, you must produce not only the load file and the associated text that has been processed from the documents, but the actual files themselves. This would include things like Word documents, Excel files, email boxes (typically a .pst file), etc.

• Redactions

Some documents that you need to produce could obtain privileged or personal information that should not be provided to the other side. If an entire document or file is privileged, it will have been designated as such in the review process and reflected in a privilege log. As part of the production process, those files will get skipped and not placed into the bucket of data that will be sent out. But if only a portion of a file needs to be obscured, then those parts will need to be redacted during review. One potential issue with this is that the load files have text (.txt) files associated with them that contain, you guessed it, the text that is pulled out of the documents and loaded into a structured database as part of processing and review. The problem with this is that those text files could potentially contain text that was redacted.

All e-discovery review platforms should have a way to indicate, at the time you run a production, if there are any redactions. If you indicate "yes," then any file that has any portion of it redacted will have its text file re-generated, with the redacted text missing. Only the text file with the redacted portions excluded will then be placed into the production set of data. Prior to actually delivering the production to the other side, a thorough quality check should be run to make certain that the redactions do not appear in any text file that will be produced.

• Delivery

Once your format has been checked against the spec sheet and your redactions have been handled and QC'd, it's time to produce the load file, image file, text files and (if requested) native files to the other side. Given the potential volume of data involved, it is exceedingly rare that you can simply email these files to the opposing side. How, then, do we get all the necessary components, consisting of the load file, image files and all associated text files (and native files if requested), into the hands of opposing counsel? Let me count the ways:

• External hard drive. These devices can hold up to two terabytes of data and can be purchased at most local office supply or computer stores for under $250. External hard drives are plugged into a server or computer via a USB cable. Once all of the production data has been copied to the hard drive, it can then be sent to opposing counsel via traceable parcel post (FedEx, UPS, etc.) or hand-delivered via courier.
• Secure file transfer websites. There are many different options here, including eShare, or secure Box or DropBox sites. Using this method, a secured, password-protected internet website link will be shared with specific individuals on the opposing side. Downloads are typically only allowed for a predetermined amount of time and are secured via SSL-encrypted links to ensure maximum security.
• SFTP—this stands for secure file transfer protocol, and almost always requires the installation of a software package that facilitates the transfer of files from a location on one computer server to another. This option also requires assistance from your (and opposing counsel's)information technology department to ensure that the transfer is completely secure, and that access is granted for a specific time period only.

Over the course of four articles, we've now looked at all of the phases of the e-discovery process at a high level. We started with ILC—identify, locate and collect. From there, we took a step back and talked about how and when to preserve data so that your production can be as thorough and as defensible as possible. We jumped back into order and talked about what to do with all that data once it was collected, by way of processing and review. This final phase described above is all about how to get that data into the hands of the other side, mostly so that we can keep ourselves in line with litigation best practices.

Besides the above exchange, my second favorite quote from "My Cousin Vinny" is this, from Vinny Gambini himself:

"It's a procedure. Like rebuilding a carburetor has a procedure. You know, when you rebuild a carburetor, the first thing you do is you take the carburetor off the manifold? Supposing you skip the first step, and while you're replacing one of the jets, you accidentally drop the jet, it goes down the carburetor, rolls along the manifold, and goes into the head. You're in trouble. You just learned the hard way that you gotta remove the carburetor first, right? So that's all that happened to me today. I learned the hard way. Actually, it was a good learning experience for me."

If you've followed along with all the articles, you'll hopefully have a better understanding of the e-discovery process, and you won't drop anything into the litigation carburetor. Understanding how everything works makes all the difference and doing the right things in the right order makes everything run smoothly. I hope you've enjoyed this series, and I'm looking forward to hearing any feedback on what you'd like to read about next!

Patrick Kennedy is the director of e-discovery for Chamberlain, Hrdlicka, White, Williams & Aughtry, a multidiscipline law firm with offices in Philadelphia, Atlanta, Houston and San Antonio. Contact him at [email protected].