A medium order of metadata, to go please Posted By Daniel Kaiser, Esq. on July 14, 2009
Some people just want it all. ESI, including metadata, is discoverable in a federal court and in state courts with similar discovery rules (thanks to Rule 34 of the Federal Rules of Civil Procedure and its state equivalents, and subject to Rule 26(b)(2)(C)’s probative value vs. burden balancing test). But if you consider the thousands of electronic documents requested in a typical corporate suit─compounded by the hundreds or thousands of pieces of metadata within an edited document─when litigants demand “all the metadata,” do they really know what they’re asking for?
What is it?
Although it can be parsed into several categories, metadata is often defined, in brief, as data about data. The Sedona Conference Glossary offers a more thorough explanation including the following:
- Data typically stored electronically that describes characteristics of ESI, found in different places in different forms. Can be supplied by applications, users or the file system. Metadata can describe how, when and by whom ESI was collected, created, accessed, modified and how it is formatted. Can be altered intentionally or inadvertently.[1]
In Aguilar v. Immigration & Customs Enforcement Div. of U.S. of U.S. Dep’t of Homeland Sec.[2], a case notable for its ruling that the preservation and production of metadata pertaining to emails and electronic files may be required in the face of appropriately timed [and supported] initial requests, a federal court provided an extensive analysis of metadata. There, for our convenience, the court broke metadata down into three categories: substantive (or application) metadata, system metadata, and embedded metadata.[3]
The Sedona Principles (Second Edition) defines substantive (application) metadata as that which “is created as a function of the application software used to create the document or file.”[4] The Aguilar court further elaborates that this metadata “reflects substantive changes made by the user . . . such as prior edits or editorial comments, and includes data that instructs the computer how to display the fonts and spacing in a document.”[5] The New York district court found a report from a working group in the District of Maryland to be persuasive in its conclusion that such “substantive metadata ‘need not be routinely produced’ unless the requesting party shows good cause.”[6]
On the other hand, system metadata “reflects information created by the user or by the organization’s information management system.”[7] This includes data regarding document titles, authors, users, computers on which electronic documents were created or accessed, and dates on which documents are created, opened, or modified. The Aguilar court noted that although such metadata will not always be relevant, it will be relevant in the event that a claim or defense turns upon “who received what information and when.”[8] For that matter, this metadata would also be relevant if a claim or defense turned upon proof of the authenticity of an electronic document or upon proof of evidence spoliation (in the form of editing or deleting portions of a document before production). The Aguilar court further notes that, significantly, system metadata adds to the functionality of the electronic documents produced in the course of discovery by “significantly improve[ing] a party’s ability to access, search, and sort large numbers of documents efficiently.”[9]
Finally, citing to Md. Protocol 27, the Aguilar court defined embedded metadata as consisting of “‘text, numbers, content, data, or other information that is directly or indirectly inputted into a [n]ative [f]ile by a user and which is not typically visible to the user viewing the output display’ of the native file.”[10] This category includes the macros and hidden fields included in spreadsheets, hyperlinks, and database information. The Aguilar court emphasizes that such metadata “is often crucial to understanding an electronic document,”[11] such as would be the case with most complex spreadsheets. Once again, the Aguilar court found the District of Maryland working group to be persuasive in concluding that “embedded metadata is ‘generally discoverable’ and ‘should be produced as a matter of course.’”[12]
All this metadata is part of what makes a native file searchable and useful. Yet due to the benefits of static images (including the ability to index and number, sort, tag, redact, and preserve the files in a permanent format), much of the ESI production in the industry today is being done via static images files such as TIFF image files. Comment 12.b. of The Sedona Principles 2d points out the importance of a load file in this scenario: “In an effort to replicate the usefulness of native files while retaining the advantages of static productions, image format productions are typically accompanied by ‘load files,’ which are ancillary files that may contain textual content and relevant system metadata.”[13]
When do I request it?
When you’re seeking another party’s metadata in the course of discovery, timing is everything. Unless metadata was requested in the initial document request, once document production has been substantially undertaken, courts have not tended to compel subsequently requested metadata production.[14] Ralph C. Losey, in his book E-Discovery: Current Trends and Cases, puts it succinctly in explaining that recent cases provide a “lesson . . . that in order to obtain metadata you may need, you should specifically ask for it to begin with.”[15] In addition to the above window of opportunity, the advisory committee’s notes for Fed. R. Civ. P. 26(f) point out that during the meet and confer, the question of whether metadata “should be produced may be among the topics discussed in the Rule 26(f) conference.”[16]
Rule 26(b)(1) of the Federal Rules of Civil Procedure casts the scope of discovery across the spectrum of “any nonprivileged matter that is relevant to any party’s claim or defense . . . subject to the limitations imposed by Rule 26(b)(2)(C)”[17] which balance probative value against potential burden. Rule 34 covers the production of documents, including Electronically Stored Information. Rule 34(b) stipulates that the request “may specify the form or forms in which electronically stored information is to be produced.”[18] Accordingly, the requesting party may specify, for example, that they want to receive electronic files in native format, PDF format, or TIFF format along with a load file containing searchable text and selected metadata. Giving the producing party 30 days from the date of service to respond, and allowing the producing party an opportunity to object to the requested format,[19] Rule 34(b)(2)(E) goes on to lay the groundwork for mandatory production:
- (E) Producing the Documents or Electronically Stored Information. Unless otherwise stipulated or ordered by the court, these procedures apply to producing documents or electronically stored information:
- (i) A party must produce documents as they are kept in the usual course of business or must organize and label them to correspond to the categories in the request;
- (ii) If a request does not specify a form for producing electronically stored information, a party must produce it in a form or forms in which it is ordinarily maintained or in a reasonably usable form or forms; and
- (iii) A party need not produce the same electronically stored information in more than one form.[20]
In the face of these provisions, the Aguilar court held that although not directly addressed in the Federal Rules of Civil Procedure, “[m]etadata . . . is discoverable if it is relevant to the claim or defense of any party and is not privileged.”[21]
What might I want to ask for?
So if “all the metadata” is going a little far, what metadata might be relevant to your claim or defense? The answer to this question will vary, case by case, according to the attributes of the underlying litigation claim. But there are a few metadata fields that can certainly be useful when facing large batches of processed data including emails and various file types. The following list is not exclusive, but these common fields may assist a reviewer:
- Beginning and Ending bates numbers
- Beginning and Ending attachment numbers
- Bates range of parent and children records
- Name of original media data came from
- Name of custodian
- Document type
- Master family date based on parent record date
- Master family time based on parent record time
- Author
- File Name
- Title
- Source
- Recipients (Including CC and BCC recipients)
- Email subject
- Created Date / Time
- Modified Date / Time
- Sent Date / Time
- Received Date / Time
- Modified by
- Accessed by
- Sort email conversation by date of parent email
- Keywords Hit
What can go wrong?
In recent months we have seen very clearly in Bray & Gillespie Mgmt. LLC v. Lexington Ins. Co. that a failure to provide metadata, when requested, may lead to adverse rulings and liability. Facing a Rule 26 conference request to produce native files with metadata, despite their right to object to the format stipulated in an ESI request,[22] the producing party “did not object to [the requesting party’s] definitions of ESI . . . or to the instructions requiring [the producing party] to produce ESI in native format with associated metadata.”[23] Yet rather then producing the ESI as requested, the producing attorneys had the ESI converted to TIFF format and produced hundreds of thousands of bare images, stripped of metadata, and practically unsearchable.
As a result the court issued sanctions, ordered ESI production as requested, ordered the producing party to grant database access to the requesting party’s computer expert, and found the partner and his firm jointly and severally liable for fees and expenses including court reporter costs, and the requesting party’s “reasonable attorney’s fees, costs, and expenses . . . incurred in filing the motion for sanctions and the proceedings arising therefrom . . . ”[24]
For some time now eDiscovery has been recognized as an integral component of traditional discovery. This case drives home the idea that, likewise, metadata is an integral factor of eDiscovery. It is clearly important to know the rules regarding requesting and producing metadata, but it is just as important to know what metadata is, how it can help you, what to ask for, and how to handle it. Comment 6.f. of The Sedona Principles 2d addresses risks to counsel in this context as follows:
. . . counsel (both inside and outside) have very practical ethical and other responsibilities to ensure that the efforts to preserve and produce electronically stored information comply with the applicable requirements . . . The volume and dynamic nature of electronic information make discovery more complex and difficult. The increased risks created by these complexities require both inside and retained counsel to meet a high standard of care in regard to discovery of electronically stored information.[25]
The use of an expert with the right knowledge and the right tools can save you money in the end.
[1] The Sedona Conference Glossary: E-Discovery & Digital Information Management (Second Edition) (December 2007), http://www.thesedonaconference.org/dltForm?did=TSCGlossary_12_07.pdf at 33.
[2] Aguilar v. Immigration & Customs Enforcement Div. of U.S. Dep’t of Homeland Sec., 2008 WL 5062700 (S.D.N.Y. Nov. 21, 2008).
[3] Id.
[4] The Sedona Principles: Second Edition, Best Practices Recommendations & Principles for Addressing Electronic Document Production, Cmt. 12a (June 2007).
[5] Aguilar, 2008 WL 5062700 (S.D.N.Y. Nov. 21, 2008), (citing Sedona Principles 2d Cmt. 12a).
[6] Id. (citing Md. Protocol 26).
[7] Id.; The Sedona Principles 2d, supra note 4, Cmt. 12a.
[8] Id.
[9] Id.
[10] Id.
[11] Id.
[12] Id.
[13] The Sedona Principles 2d, supra note 4, Cmt. 12b.
[14] See D’Onofrio v. SFX Sports Group, Inc., 247 F.R.D. 43, 48 (D.D.C.2008); See also Treppel v. Biovail Corp., 233 F.R.D. 363, 374 (S.D.N.Y.2006) (requiring native format production, including metadata, where requesting party asked for it and received no objection from the producing party); See also Autotech Techs. Ltd. P’ship v. Automationdirect.com, Inc., 248 F.R.D. 556 (N.D. Ill. 2008) (requestor not entitled to native production when requested only after production received in .pdf and paper format); See also The Sedona Principles 2d, supra note 4, Cmt. 12d. (“Parties need not produce the same electronically stored information in more than one format”).
[15] Ralph C. Losey, E-Discovery: Current Trends and Cases 158-59 (2007).
[16] Fed. R. Civ. P. 26(f) advisory committee’s note, 2006 amendment; See also The Sedona Principles 2d, supra note 4, Cmt. 4a. (“Requests for production should clearly specify what electronically stored information is being sought”).
[17] Fed. R. Civ. P. 26(b)(1).
[18] Fed. R. Civ. P. 34(b)(1)(C).
[19] Fed. R. Civ. P. 34(b)(1)(D); See also The Sedona Principles 2d, supra note 4, Principle 6 (“Responding parties are best situated to evaluate the procedures, methodologies, and technologies appropriate for preserving and producing their own electronically stored information”).
[20] Fed. R. Civ. P. 34(b)(2)(E).
[21] Aguilar, 2008 WL 5062700 (S.D.N.Y. Nov. 21, 2008).
[22] Fed. R. Civ. P. 34(b)(2)(D).
[23] Bray & Gillespie Mgmt. LLC v. Lexington Ins. Co., 2009 WL 546429, 5 (M.D. Fla. Mar.4, 2009).
[24] Id. at 25.
[25] The Sedona Principles 2d, supra note 4, Cmt. 6.f.
Post A Comment