Suspect that you received an incomplete production? Check the load file.

PrecisionDiscovery_BlogIMGProduction_1027_4.jpg

Proactive Discovery Series | Productions Received Explainer

A long-awaited production lands on your desk. You hand it off to the tech team for loading and analysis, but when the data are released for review, you notice that something isn’t right. Emails with attachments don’t seem to have any document family, or there are no Custodian values for the first few documents you review.  

Even though an ESI protocol has been negotiated, and even though the delivery format of images/text/natives/metadata have all been stipulated, loading and reviewing a production received always seems to have a hidden “gotcha” or a quirk that pops up.

  • Mysterious additional load files that are not referenced in the cover letter.
  • Production Bates number gaps in the the middle of a production.
  • And then there’s that old chestnut – everyone’s favorite – stipulated metadata fields that aren’t produced.

What do you do?

Check the Load File!

Adding to the original analysis in our previous Proactive Discovery article, “Light it Up! Understanding the Format and Specifications of a Production,” let’s take a quick trip to load file land, where everything is delimited – if it’s done right.

“Load files are the glue that hold the images, natives, metadata and searchable text together for attorney review.” – Light it Up! Understanding the Format and Specifications of a Production

So How Do You Check a Load File, Anyway?

Load files are informational files about the rest of the production. They usually contain metadata extracted from and assigned to the documents they accompany, and they often contain pointers linking a document’s data to its associated images, text and natives.

MSWord documents generally don’t have Sent Dates or From metadata. I say “generally” because this is eDiscovery, people! Nothing is “always the case.

If the production received came with a load file, open it in a text editor like TextEdit (Mac) or NotePad (Windows). Once the file is open, the first line lists all of the metadata fields in the load file; it is called the “header row.” The header row should have every field in the ESI production protocol, but it should not be mistaken for a full list of every metadata field available.

It is also worth noting that NOT every document will have every metadata field populated. For example, MSWord documents generally don’t have Sent Dates or From metadata. I say “generally” because this is eDiscovery, people! Nothing is “always the case.”

The Load File is Open… Now What?

With the load file open in the text editor, you can make a quick assessment of whether you were provided all the metadata to which you were entitled by spot checking the rows for populated fields. If you want a more comprehensive analysis, you could import the load file into Excel, turn on filters based on the header row and start doing some deep digging – but that’s only if you’re hardcore.

image002.png

If fields are blank, and you were entitled to metadata for those fields, you know right away that you have not received all the information you should have. Knowing about missing data before undertaking review can be a big cost saver. Jumping into a data set only to discover later that it doesn’t have email family metadata or email address fields could waste the most important resource you have: time.

So start with a load file analysis to look for production omissions, mistakes and misunderstandings within hours of receiving a production – because quick reporting of production issues can set the stage for faster fixes and greater cooperation.

Extracted v. Assigned Metadata

Not all load file fields are metadata that have been extracted from the files themselves – some fields are assigned and associated with each record. There may be purists who feel that only fields extracted from a file can be considered true metadata. But for simplicity sake, let’s consider all fields in a load file that associate fielded information with a specific record to be metadata for that record within the context of the production.

  • Extracted File Metadata – These data are actually extracted from the file and put into the associated metadata field. Examples include: From, To, CC, BCC, Sent Date, Sent Time Subject and Author
  • Assigned File Metadata – These are data that documents don’t have or contain “in the wild.” For example, Bates numbers are assigned to a record, and that only happens after processing, imaging and Bates branding. Another example is the Custodian field.

What’s Next?

This article is the second article in our Proactive Discovery Series: Productions Received. Stay tuned for more Explainers, where we will dig into the day-to-day discovery issues that vex us all. The plan is to sort out some of the muck to shed light on “How Stuff Works” that can help make the sprawling, shifting and complicated process of eDiscovery more comprehensible and manageable.

aaron_patton_headshot.jpg

Aaron Patton, Managing Director

Aaron Patton is a managing director at Precision Discovery who is always on the hunt for common sense solutions to persistent discovery problems. As a Wisconsin Law graduate (2001), Aaron is fascinated by “Law in Action”, especially the intersection of discovery rules and discovery reality. Aaron is based in the Washington, DC area.`

 

 

Jeremy Applebaum.jpg

Jeremy Applebaum, eDiscovery Consultant

Jeremy Applebaum, a 2004 graduate of Cumberland School of Law, is an eDiscovery Consultant with Precision Discovery. He has successfully navigated cases ranging from personal injury to complex environmental contaminations and large product liability actions. Jeremy recognizes the importance of focused and productive discovery, and enjoys using his experience to guide others through this process.

Visit Jeremy on LinkedIn

 

Aaron PattonComment