Proposed Language for Hyperlinked Files in ESI Protocols: eDiscovery Trends

Beware of geeks bearing “gifts”, even in the holiday season! Here is my attempt at proposed language for hyperlinked files in ESI protocols!

Over the past few months, I’ve written several posts regarding the issue of hyperlinked files as “modern attachments”, including previous case law (here and here), five proposed assumptions to simplify the debate, the primary argument for treating hyperlinked files as modern attachments, and a new Google feature that supports exporting of hyperlinked files from Vault linked via Gmail.

With all that in mind, it’s time to take a leap of faith! So, I have proposed language for hyperlinked files that could be added into an ESI protocol.

My goal was to propose language that addresses the need to produce the relevant information, but in a way that attempts to appropriately limit the scope of hyperlinked files being produced. I would envision this language appearing after language in an ESI protocol that addresses parent-child relationships to set the parameters, but I have not proposed that the hyperlinked files must be treated as “children” to parent emails or other communications and have not used the phrase “modern attachments”. The goal is to simply provide the ability for the requesting party to reasonably get to files that are hyperlinked within those communications and understand the relationship between the communications and the hyperlinked files.

Here’s the proposed language for hyperlinked files (embedded numbers are to illustrate points below and wouldn’t be included in the actual text):

Hyperlinked Files. Hyperlinked files (1) within any responsive email or other collaborative communication within the possession, custody and control (2) of the producing party will be produced and cross-referenced to the communications from which they are linked, either by treating them as a parent-child relationship or via metadata that identifies the link between the communication and the hyperlinked file. For any hyperlinked files that are no longer available, the producing party will provide an exception report to identify those files (3). If the exact version of any hyperlinked file is no longer available, the producing party will produce the closest available version of that file after the date/time of the exact version. If the producing party is unable to meet any of these requirements due to technical challenges, it will request to meet and confer with the requesting party to discuss alternatives that will be proportional to the needs of the case. (5)

What do the numbers represent? They represent the assumptions that I proposed back in this post. As a reminder, they are:

1. The issue relates only to hyperlinked files, not all hyperlinks.
2. Those hyperlinked files must be in the “possession, custody or control” of the responding party.
3. A file that no longer exists can’t be produced.
4. Hyperlinked files should still be produced if they are deemed to be responsive.
5. Discovery of hyperlinked files must be both relevant and proportional.

As you can see, production is limited to hyperlinked files (1) in the “possession, custody or control” (2) of the responding party, there’s an out (with accountability) for files that no longer exist (3), and an option to meet and confer to discuss barriers that may keep production from being proportional (5). The versioning issue is addressed in the only reasonable way I can think of – produce the closest version to the one sent if the exact version isn’t available.

What about #4? These files should still be produced stand-alone if they’re responsive, but if they’re not linked to a responsive message, there is no need to identify that relationship, so it doesn’t figure into the language above, which focuses on hyperlinked files to responsive messages only.

Hopefully, this language represents a reasonable approach that balances the need for producing relevant information while also providing allowances for some of the difficulties in doing so when it comes to hyperlinked files. For it to work, parties need to be reasonable and cooperate – just like with any other discovery issue.

Having said that, I encourage feedback on this proposed language for hyperlinked files. Am I missing any scenarios? Is it unreasonable to one side or the other (or even both, if that’s possible)? I’m prepared for feedback, even if it’s brutally honest (or just plain brutal).

So, what do you think? Would you consider using this proposed language in an actual ESI protocol? Please share any comments you might have or if you’d like to know more about a particular topic.

Image created using Microsoft Bing’s Image Creator Powered by DALL-E, using the term “email AND hyperlinks”.

Disclaimer: The views represented herein are exclusively the views of the authors and speakers themselves, and do not necessarily represent the views held by my employer, my partners or my clients. eDiscovery Today is made available 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 Today should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.