It’s the month for giving thanks, and I’m ever-grateful for the daily e-discovery blog penned by my friend, Doug Austin, for CloudNine.  It’s tough to get out a post every business day, and Doug’s done it splendidly for, what, nine years now?  Kudos!  Doug’s EDiscovery Daily blog is often my first heads-up for new e-discovery cases, true again for the decision he featured this morning,  Metlife Inv’rs. USA Ins. Co. v. Lindsey, No. 2:16-CV-97 (N.D. Ind. Oct. 25, 2018)

It’s a familiar scenario.  The requesting party expressly demands native file production.  The responding party, a big insurance company, produces static image formats as non-searchable PDFs.  When the requesting party objects, the carrier argues that the metadata it strips from the evidence isn’t relevant and that the request for native forms is disproportionate, again challenging relevance, and also claiming that producing in the native forms sought would be cumulative because (chutzpah!) they’d already produced in PDF over their opponent’s timely objection.

To its credit, the Court makes short work of MetLife’s high-handedness and orders native production but stumbles a bit on the relevance and scope issues.  The Court addresses the relevance objection by noting that native production may shed light on who accessed information and that this may inform whether the insurer had a duty to investigate the policy application.  Maybe.  More likely, it won’t.  But, the Court shouldn’t have let itself be drawn in by a specious relevance challenge.

There are two varieties of file metadata: application metadata and system metadata.  Relevance should never matter for application metadata or dog tag system metadata.  If a file is sufficiently relevant to be responsive, no requesting party should be required to further demonstrate that metadata within the file is independently relevant.  The burden to prove a right to excise parts of relevant files should rest with the party altering the evidence.  Moreover, a file’s name, path and last modified date (“dog tag” metadata) are so patently useful that their utility more than relevance should serve as  sufficient basis for the production of essential system metadata.

The Court reached the right result for wrongly-articulated reasons. Metadata remains the most misunderstood information in e-discovery, and I just don’t get why that’s still the case.

The Court added this dicta, “While production in native format will inevitably result in the exchange of some metadata, Defendants are not entitled to all metadata generally, except to the extent it appears with the documents as kept in the usual course of business.”  I share the sentiment; but the way it’s laid out muddies the water.

Application metadata is integral to native documents.  System metadata is readily available to any user who seeks it out; in Windows, you’ve only to right click on the column titles of a Windows Explorer screen to see a huge menu of metadata values you can display.  Thus, ‘all’ metadata satisfies the Court’s formulation, as essentially all metadata “appears with the documents as kept in the usual course of business.”

When you produce in native forms, you necessarily produce all application metadata. Why? Because it’s part and parcel of the native form. It’s embedded in the native file. So, unless a party acts to alter or destroy application metadata, it’s coming along–ALL of it, whether you ask for it or not. The external metadata–system metadata–is a complement of information that is not stored within the file but is housed in the file table of the file system for the device or media storing the file. System metadata are important stuff, including the name assigned the file, the location (path) of the file and dates and times shedding light on the origins and usage of the file.  There’s other system metadata, but it’s rarely sought or used. My guess is those obscure system metadata values were not what these litigants were fighting over.

You shouldn’t have to specifically request application metadata when native production is sought because you shouldn’t have to specifically demand that a party not alter or corrupt evidence before production. Yet, a request for native production IS a specific request for application metadata because application metadata is inherently part of the native file and travels with every copy of the native file.

Although it’s a prudent practice to spec the contents of the load file in your request, why would we require a party to expressly request everyday items of system metadata so essential to a file’s utility that for a party to seek to alter or exclude them is suspect? Here, I’m speaking of file name, path and last modified date and time. If you’re using item identifiers like Bates numbers, it only makes sense to supply those, too.

There are different considerations for database content and the rare proprietary system; but, for your run-of-the-mill Windows or Mac operating system, producing these metadata is just common sense. I ask you, Dear Reader, what moves lawyers to be so obtuse about something so easily understood? Application metadata is in the file; system metadata is the tracking information that’s outside the file and key to the identification and origination of the file. Rocket science?  Not even close.

Can we stop the metadata madness? Please?  Thank you.

For more about metadata, check out my oldie-but-goody, Beyond Data-About-Data: The Litigator’s Guide to Metadata.