Elawyers Elawyers
Washington| Change

Nix v. Chemours Company FC, LLC, 7:17-CV-00189-D (2019)

Court: District Court, E.D. North Carolina Number: infdco20191015e06 Visitors: 11
Filed: Oct. 11, 2019
Latest Update: Oct. 11, 2019
Summary: STIPULATION AND ORDER ON DISCOVERY OF ELECTRONICALLY STORED INFORMATION ROBERT T. NUMBERS, II , Magistrate Judge . Pursuant to Fed. R. Civ. P. 16 and Fed. R. Civ. P. 26(f), the Court adopts and enters as an Order the parties' Stipulation and Order on Discovery of Electronically Stored Information. The procedures and protocols outlined herein govern the production of electronically stored information ("ESI") and paper documents that are produced in an electronic format (the "ESI Protocol") o
More

STIPULATION AND ORDER ON DISCOVERY OF ELECTRONICALLY STORED INFORMATION

Pursuant to Fed. R. Civ. P. 16 and Fed. R. Civ. P. 26(f), the Court adopts and enters as an Order the parties' Stipulation and Order on Discovery of Electronically Stored Information. The procedures and protocols outlined herein govern the production of electronically stored information ("ESI") and paper documents that are produced in an electronic format (the "ESI Protocol") on or after the date of this Order. All disclosures and productions made pursuant to the ESI Protocol are subject to the Stipulated Protective Order. The parties will confer, if needed, for production formats for particular materials that are not addressed herein.

I. General Provisions

A. Counsel for Plaintiffs, E.I. DuPont de Nemours ("DuPont"), and The Chemours Company FC, LLC ("Chemours") have met and conferred regarding discovery of electronically stored information and have reached agreement on certain of the issues discussed regarding such discovery. The parties agree that the efficient and just resolution of this matter will be furthered by mutual cooperation and transparency in responding to the parties' requests for documents, and the parties intend to promote, to the fullest extent possible, the resolution of disputes regarding the discovery of ESI without Court intervention. The parties do not intend by entering this stipulation to waive any privilege, work product protections, or other protections or objections in responding to discovery.

B. The Federal Rules of Civil Procedure will govern discovery, and no provision herein alters any provision of the Federal Rules of Civil Procedure, local rules, or applicable law. The terms of this Order shall be construed to ensure the cost-efficient and cost-effective exchange of information consistent with the Federal Rules of Civil Procedure, local rules, and applicable law.

II. Definitions

A. "Confidentiality Designation" means the legend affixed to Documents for confidential and highly confidential discovery information as defined by, and subject to, the terms of the parties' Stipulated Protective Order.

B. "Document" has the meaning contemplated in the Federal Rules of Civil Procedure and, includes, without limitation, all ESI. The term "Document" includes Hard-Copy Documents, Electronic Documents, and other ESI.

C. "Electronic Document or Data" means Documents that are in electronic form at the time of collection.

D. "Electronically stored information" or "ESI," means electronically stored information, as that term is used in Federal Rule of Civil Procedure 34(a).

E. "Hard Copy Document" means a document that is stored in paper form at the time of collection.

F. "Hash Value" is a number that uniquely identifies a file or specific data and that is calculated using a standard mathematical hashing algorithm whose input comprises characteristics of the respective file or data.

G. "Load File" is an electronic file that can assist in loading an electronic production set into a receiving party's document review platform. For example, as described more fully below, a Metadata Load File contains Metadata about the electronic production set, and an Image Load File contains information to facilitate loading document images into the document review platform.

H. "Metadata" are information embedded in or associated with an Electronic Document that are generated automatically by the operation of a computer or other information technology system when the document is created, modified, transmitted, deleted, or otherwise manipulated. The parties will not be required to manually populate any metadata fields.

I. "Media" means an object or device, real or virtualized, including but not limited to a disc, tape, computer or other device, on which data is or was stored.

J. "Native Format" means the original format of ESI in which it was generated, used and/or normally kept by the producing party in the usual course of its business and in its regularly conducted activities. For example, the native format of an Excel workbook is a .xls or .xslx file.

K. "OCR" is an abbreviation for "optical character recognition" and references a process by which text contained within an Electronic Document in a non-searchable imaged format is converted to a searchable text format.

L. "Producing Party" means the Party producing documents during discovery.

M. "Receiving Party" means the Party receiving documents during discovery.

N. "Static Image(s)" means a representation of ESI produced by converting a Native File into a standard image format capable of being viewed and printed on standard computer systems. A Static Image may also be created by scanning a Hard-Copy Document. A Tagged Image File Format (TIFF) image is an example of a Static Image.

III. Form of Production

The parties will produce Documents in "a reasonably usable form." Fed. R. Civ. P. 34(a)(1)(A). If a Party has previously processed or produced certain Documents in a form that is different than that provided for herein, the Party is not required to produce the Documents in accordance with this Protocol, provided that the form utilized is also "reasonably usable." The requesting party reserves the right to object to whether the form utilized is "reasonably usable." Notwithstanding the foregoing, the parties agree that the following forms of production are "reasonably usable": documents produced as TIFF images with load files utilizing Concordance default delimiters, and files produced in native format pursuant to Section III.B with an accompanying placeholder image/slip sheet bearing the Bates number and any confidentiality designation required by the Parties' protective order.

A. Paper Documents/Hard Copy Scanned Images.

1. Paper documents may be produced in hard-copy paper form. If a Party has converted paper documents into an electronic form, including by scanning, then the Party will produce those electronic scans in the form of TIFF images using best efforts in the unitization of the document. The production will include a Metadata Load File and an Image Load file as described more fully below in Section III.C. The Producing Party will not be required to manually populate any of the fields in either Load File. The parties agree that to the extent the Producing Party scanned hard copy documents prior to the entry of this Order, the Producing Party is not required to re-scan those hard copy documents.

2. To the extent practicable, paper documents and hard copy scanned images shall be produced in the manner in which those documents were kept in the ordinary course of business. Where a paper document or hard copy scanned image has identification spines, "post-it" notes, or any other labels, the information on the label shall be scanned and produced to the extent practicable. In scanning a paper document, if a document is more than one page, to the extent reasonable, the unitization of the document and any attachments or affixed notes should be maintained as it existed when collected by the producing party. The parties will utilize reasonable best efforts to ensure that paper documents and/or hard copy scanned images in a single production are produced in consecutive Bates number order.

B. ESI

1. Except as otherwise provided herein, the parties shall produce ESI in TIFF format with a Metadata Load File, an Image Load File, and a corresponding text file. Word processing files, including Microsoft Word files, will be produced as TIFF images in "last saved" or "last modified" format and with tracked changes and comments showing in the TIFF image and searchable in the extracted text, to the extent tracked changes and comments exist in the "last saved" or "last modified" format. Presentation files, including PowerPoint, will also be produced as TIFF images in "last saved" or "last modified" format with any speaker notes and hidden slides showing and searchable in the extracted text, to the extent speaker notes and hidden slides exist in "last saved" or "last modified" format. Audio files in non-standard formats should be produced in MP3 or Native Format. Unless redacted, the following files shall be produced in Native Format with extracted text and applicable Load Files: (a) electronic spreadsheets (e.g., Excel); (b) desktop databases (e.g., Access); and (c) audio/video multimedia files. A producing party may also elect to produce electronic presentations (e.g., PowerPoint) or word processing files (e.g. Word) in Native Format with extracted text and applicable metadata fields set forth in Attachment A; these files may otherwise be produced in TIFF format as provided for herein. The parties reserve the right to request unredacted electronic presentations (e.g., PowerPoint) produced in TIFF format in Native Format as necessary. If a document that otherwise would be produced in Native Format requires redaction, such document may be produced as redacted in TIFF format or Native Format in accordance with this Protocol and in compliance with Section III.B.2. If a party produces a redacted document in TIFF format, a corresponding Native File version need not be produced, and the TIFF version must display the above-referenced content such as tracked changes, comments, speaker notes, hidden slides, and similar content. The redacted TIFF image will be OCR'd to create a text file that shall be produced in lieu of extracted text.

2. All TIFF-formatted documents will be produced in black-and-white as single page Group IV, 300 DPI, when reasonably practicable. Image file names will be identical to the corresponding Bates numbered images, with a ".tif" file extension. The requesting party retains the right to request a TIFF image in a higher resolution or larger page size if necessary to render the image legible or reasonably usable. If a party encounters a document where color is reasonably necessary to comprehend the content, the producing party will cooperate to honor reasonable and specific requests to re-produce that document in a color format. All images of redacted documents that contain comments, deletions, revision marks (including the identity of the person making the deletion or revision and the date and time thereof), speaker notes, or other user-entered data that the source application can display to the user will be processed such that all data is visible in the image, to the extent it exists in "last saved" or "last modified" format. For instances in which only a portion of a document is redacted for privilege, the party claiming the privilege will redact only the privileged portions and produce the remaining portions. The party may, at its option, indicate the basis on the face of redaction. Documents that are partially redacted for privilege and that indicate on their face the basis of the redaction on grounds of privilege need not be placed on a privilege log if (a) the document's metadata indicates the document has been redacted for privilege and (b) the non-redacted portions provide sufficient context to identify and evaluate the basis of the claim of privilege. The receiving party may request that the producing party provide an explanation of the basis of claim of privilege for specific redacted documents and such request shall not be unreasonably denied. The Producing Party's production of a text file or Metadata Load File containing information redacted from that Document shall not be deemed a waiver of the privilege or other protection associated with that Document, and any metadata or text file containing the text of redacted portions of a redacted Document or other privileged or protected information shall be treated as protected information, consistent with the terms of clawback provisions of the parties' Stipulated Protective Order.

3. All images must be assigned a Bates number that shall always: (1) be unique across the entire document production, (2) maintain a constant length (zero/0-padded) across the entire production, (3) contain no special characters or spaces, and (4) be sequential within a given document. Bates numbers shall not obscure any portion of the original file. If Bates numbers are skipped in a production range and not otherwise identified in a privilege log, then the producing party will disclose the Bates numbers or ranges in a cover letter accompanying the production. A single text file (.TXT) will be provided for each document produced. The text file name will be the same as the Bates number of the first page of the respective document, with the extension ".txt" suffixed. Electronic text must be extracted directly from the Native File unless the document requires redaction, is originally an image file, is any other Native File that does not contain text to extract (e.g., non-searchable PDFs), or where text cannot practicably be extracted. In these instances, and in the case of imaged hard-copy documents, the TIFF image will be OCR'd to create a text file that shall be produced in lieu of extracted text. Extracted text shall be provided in UTF-8 format text and may include a Byte Order Mark. Extracted text shall include all available comments, revisions, tracked changes, speaker's notes, text from documents with comments or tracked changes, as well as hidden worksheets, slides, columns, and rows. Text extracted from emails shall include the following header information that would be visible if the email was viewed in the e-mail application: (1) the individuals to whom the communication was directed ("To"), (2) the author of the email communication ("From"), (3) who was copied and blind copied on such email ("CC" and "BCC"), (4) the subject line of the email ("RE" or "Subject"), and (5) the date and time of the email. The full path of the text file must be provided in the Metadata Load File.

4. The parties will disclose the time zone used for field dates and times.

5. OLE embedded objects (embedded MS Office files, etc.) shall be extracted as separate files and treated as attachments to the parent document where practicable. Images embedded in emails shall not be produced as attachments unless they are responsive to a discovery request served upon the producing party, e.g., logos and junk files embedded in emails do not need to be produced as attachments.

6. Documents that contain languages other than English, in whole or in part, shall be produced in the original language(s).

7. OCR software should be set to the highest quality setting during processing. Settings such as "auto-skewing" and "auto-rotation" should be turned on during the OCR process. A Bates-stamped placeholder TIFF, bearing a legend indicating that the document was produced natively shall be provided for ESI produced in native format, unless the document is also produced in TIFF format. These placeholders will be Bates numbered in the same way as any other TIFF, and the Bates number of that single page shall be used as the BegBates and EndBates of the associated document, and the "PGCOUNT" field in the Metadata Load File for the placeholder shall contain "1."

8. The parties will meet and confer to address the production and production format of any responsive data contained in a database or other structured or aggregated data source under the possession, custody, or control of the parties. The parties anticipate that certain productions of structured data may require the parties to first exchange information about the pertinent database, including to discuss the efficient retrieval and production of data contained therein.

9. Parent-child relationships (the association between an attachment and its parent document or between embedded documents and their parent) shall be preserved. A document and all other documents in its attachment range, emails with attachments, and files with extracted embedded OLE documents all constitute family groups. If any member of a family group is produced, all responsive members of that group must be also be produced. If a party does not produce a member of a family group on the grounds that it is non-responsive, then the party will include a slip-sheet stating that the attachment is withheld as non-responsive, unless the attachment is a non-responsive OLE embedded object as set forth in Section III.B.5 above. The parties may meet and confer to discuss requests to produce an attachment that has been slip-sheeted as non-responsive.

10. A Producing Party will take reasonable steps to unencrypt any discoverable ESI that exists in encrypted form (e.g., password-protected) and that can be reasonably unencrypted. A Producing Party will not be required to guess passwords or otherwise produce documents that are not reasonably accessible.

11. The parties will use best efforts to produce responsive social media in accordance with this Order, but where it is not reasonably practicable to produce responsive social media in the manner set forth in this Order, the parties shall meet and confer to discuss the most practicable manner of production. In connection with such discussions, the Producing Party shall produce a test production when requested by a receiving party. In general, even where social media cannot be produced in accordance with this Order, a Producing Party must produce responsive social media in a reasonably usable form.

12. Absent a specific showing of need, the following categories of ESI are not discoverable in this case: deleted, slack, fragmented, or unallocated data on media; random access memory (RAM) or other ephemeral data; and online access data such as temporary internet files, history, cache, cookies, etc. Federal Rule of Civil Procedure 37(e) governs the loss of electronically stored information that should have been preserved in the anticipation or conduct of litigation because a party failed to take reasonable steps to preserve it and it cannot be restored or replaced through additional discovery. If a party demonstrates a specific need for information encompassed by this section and to the extent such information exists, the parties shall meet and confer on whether such data should be produced, preserved on a forward-looking basis, and/or whether cost-shifting is appropriate. However, prior to a showing of a specific need and an agreement among the parties on the need or Court order accepting the need, there shall be no obligation to preserve such information.

13. Common system and program files as defined by the NIST library need not be preserved, collected, processed, reviewed, or produced.

C. Load Files. There will be two Load/Unitization files accompanying all productions. One will be the Image Load File and the other will be the Metadata Load File. The specifics of these files are set forth below. To the extent a Producing Party departs from the specifics of these files, it shall disclose such deviation to the receiving party. The parties will use consistent load file parameters throughout their respective productions.

1. Image Load File

(a) Every Document referenced in a production Image Load File shall have all corresponding images, text, and data logically grouped together in a directory structure with a common key to properly load the data. (b) Documents shall be produced in only one Image Load File throughout the productions, unless that document is noted as being a replacement document in the Replacement field of the corresponding Metadata Load File. (c) If produced on media, the name of the Image Load File shall mirror the name of the delivery volume or the production date, and should have an .lfp, .opt or .dii extension (e.g., ABC001.lfp). If named by delivery volume, the volume names shall be consecutive (i.e., ABC001, ABC002, et seq.). *If a .dii file is produced, the accompanying Metadata Load File shall be separate from the .dii file and not contained within the .dii file. The Image Load File shall contain one row per TIFF image. (d) Every image in the delivery volume shall be referenced by Bates number in the Image Load File. (e) The image key shall be named the same as the Bates number of the page. If produced on media, load files shall not span across media (e.g., CDs, DVDs, hard drives, etc.). In other words, a separate volume shall be created for each piece of media delivered.

2. Metadata Load File

(a) The metadata load file shall use Concordance default delimiters, or if a party is using different delimiters then the delimiters will be disclosed. (b) Data for a document shall be produced in only one data load file throughout the productions, unless that document is noted as being a replacement document. (c) The first record shall contain the field names as columns in the order of the data set forth in Attachment A, infra. Metadata fields that are not applicable to a document shall be filled with a NULL value or left blank along with fields that were not able to be obtained due to a processing error or corrupt file. (d) Date fields shall be produced in "mm/dd/yyyy hh:mm:ss AM" or "M/D/YYYY hh:mm:ss AM" format. (e) A carriage-return line-feed shall be used to indicate the start of the next record. (f) Load Files shall not span across media (e.g., CDs, DVDs, hard drives, etc.). In other words, a separate volume shall be created for each piece of media delivered. (g) The name of the Metadata Load File shall mirror the name of the delivery volume or production date, and shall have a .dat, .csv or .txt extension (i.e., ABC001.dat). (h) The volume names shall be consecutive for each produced source (i.e., ABC001, ABC002, et seq.).

D. De-duplication. "Duplicate ESI" means, for a stand-alone document, that one document is the exact duplicate of another stand-alone document, or for an e-mail family, that one e-mail family is the exact duplicate of another e-mail family based on the stand-alone files' or the e-mail families' identical MD5 or SHA-1 Hash Values. The producing party need only produce a single copy of responsive Duplicate ESI. However, no document that is a member of an e-mail family or is the parent or an attachment of a produced document may individually be withheld from production as a duplicate, and no stand-alone document may be withheld as a duplicate based on the presence of that stand-alone document within an e-mail family. If a producing party de-duplicates documents across its various productions, then the producing party shall provide the names of all original file locations of the duplicates of a particular document in the relevant load file. A Producing Party employing a deduplication process certifies that its process is commercially acceptable. The Producing Party agrees that the presence of a custodian's name contained in "all custodians" or "other custodians" in the metadata for a particular document is evidence that a duplicate of the document was located in that custodian's file.

E. E-mail Threading. The Parties may use industry standard "email thread suppression." As used in this Protocol, email thread suppression means reducing duplicative production of email threads by producing only the most inclusive email containing the thread of emails, as well as all attachments within the thread. Duplicative emails suppressed under this paragraph need not be reflected on the Party's privilege log. If the most inclusive email in a thread is redacted in its entirety as privileged, but earlier emails in the thread are responsive and not privileged, then the unredacted portion of the thread must be produced.

F. Proprietary Software. To the extent that relevant ESI cannot be rendered or reviewed without the use of proprietary software that is not commercially available, the parties shall meet and confer to discuss and attempt to reach a mutually agreeable resolution.

G. Redactions. Except as provided in paragraph 13 above regarding non-responsive attachments, no redactions for relevance may be made within a produced document or ESI item. For redacted items that were originally ESI, all applicable metadata fields will be provided and will include all non-redacted data. Redacted documents need not be logged as long as the Metadata Load File indicates the document is redacted for privilege and (a) for e-mails, the information in the Metadata Load File for the document is not redacted, and (b) for non-e-mail documents, the redaction is noted on the face of the document. The receiving party may request that the producing party provide an explanation of the basis of claim of privilege for specific redacted documents and such request shall not be unreasonably denied.

H. Production Media. The producing party will use the appropriate electronic media (CD, DVD, flash/thumb drive or hard drive) for its ESI production and will cooperate in good faith to use media with the appropriate storage capacity to minimize associated overhead. A party who receives a production on a hard drive must return the drive to the producing party after transferring the data. Alternatively, a party may produce via a secure FTP or Sharefile link, provided that, after making such a production, the producing party honors timely and reasonable requests for a copy provided on physical media if the size of the production imposed an unreasonable burden on the receiving party to download the files. If a party produces a replacement production, the party will cross-reference the original production and identify the replacement as being a replacement.

I. Production Problems. If a receiving party believes that a document, as produced, does not comply with the production format requirements herein, the receiving party may notify the producing party of the alleged non-compliance, and as necessary, the parties will promptly meet and confer regarding a reasonable resolution of any such production-format issue. If the party identifying the issue can provide samples (i.e. documents' Bates numbers) of an issue, it should do so.

IV. ESI Procedures

A. Cooperation. The parties shall conduct discovery in a cooperative manner and shall meet and confer in good faith on issues as may arise during the course of discovery.

B. Search Methodologies. Search terms may be used to identify files for review and production. To the extent a producing party wishes to use search terms, technology-assisted review, or other electronic search methodologies to cull documents from review and production, the parties shall meet and confer and attempt in good faith to reach agreement regarding the search methodology, including the identities of custodians from whom ESI will be collected and searched.

V. General Provisions.

A. The parties agree to exchange search terms to the extent they intend to apply them to their respective ESI and agree to meet and confer over the use of search terms in an effort to reach agreement on them, including whether the use of certain hit reports and/or sampling would be reasonable and appropriate. If a party uses predictive coding, then before doing so, that party will first disclose its intended use and meet and confer with the parties to reach agreement on the method that will be applied.

B. This Protocol does not address, limit, or determine the authenticity, admissibility, or relevance of any Document.

C. Nothing in this Protocol shall be interpreted to limit a Producing Party's right to conduct a review of Documents, including metadata, for relevance, responsiveness, or segregation of privileged or protected information before production.

D. Any practice or procedure set forth herein may be varied by agreement of the parties, and such variance first will be confirmed in writing, where such variance is deemed appropriate to facilitate the timely and economical exchange of electronic data or other covered discovery materials.

E. Should any party subsequently determine in good faith that it cannot proceed as required by this Order or that the Order requires modification, the parties will meet and confer to resolve any dispute before seeking Court intervention.

DATED: October 8, 2019 By: /s/ Theodore J. Leopold By: /s/ Kenneth J. Reilly Theodore J. Leopold John K. Sherk III COHEN MILSTEIN SELLERS Tammy B. Webb & TOLL PLLC SHOOK, HARDY & BACON, LLP 2925 PGA Boulevard, Suite 220 One Montgomery Tower, Suite 2600 Palm Beach Gardens, FL 33410 San Francisco, CA 94104 (561) 515-1400 Telephone Telephone: 415-544-1900 (561) 515-1401 Facsimile Facsimile: 415-391-0281 tleopold@cohenmilstein.com jsherk@shb.com tbwebb@shb.com Jay Chaudhuri N.C. Bar No. 27747 Kenneth J. Reilly COHEN MILSTEIN SELLERS SHOOK, HARDY & BACON, LLP & TOLL PLLC Citigroup Center, Suite 3200 150 Fayetteville Street Suite 980 201 South Biscayne Boulevard Raleigh, NC 27601 Miami, FL 33131-4332 (919) 890-0560 Telephone Telephone: 305-358-5171 (919) 890-0567 Facsimile Facsimile: 305-358-7470 jchaudhuri@cohenmilstein.com kreilly@shb.com Andrew Whiteman Jonathan D. Sasser N.C. Bar No. 9523 Stephen D. Feldman WHITEMAN LAW FIRM ELLIS & WINTERS, LLP 5400 Glenwood Ave., Suite 225 P.O. Box 33550 Raleigh, NC 27612 Raleigh, NC 27636 (919) 571-8300 Telephone Telephone: 919-865-7000 (919) 571-1004 Facsimile Facsimile: 919-865-7010 aow@whiteman-law.com jon.sasser@elliswinters.com stephen.feldman@elliswinters.com S. Douglas Bunch Douglas J. McNamara Attorneys for Defendants Jamie Bowers Alison Deich COHEN MILSTEIN SELLERS & TOLL PLLC 1100 New York Ave., N.W. Suite 500 Washington, D.C. 20005 (202) 408-4600 Telephone (202) 408-4699 Facsimile dbunch@cohenmilstein.com dmcnamara@cohenmilstein.com jbowers@cohenmilstein.com adeich@cohenmilstein.com Vineet Bhatia SUSMAN GODFREY, L.L.P. 1000 Louisiana Street, Suite 5100 Houston, TX 77002 (713) 651-3666 Telephone (713) 654-6666 Facsimile vbhatia@susmangodfrey.com Stephen Morrissey Jordan Connors Steven Seigel SUSMAN GODFREY, L.L.P. 1201 Third Ave. Suite 3800 Seattle, WA 98101 (206) 516-3880 Telephone (206) 516-3883 Facsimile smorrissey@susmangodfrey.com jconnors@susmangodfrey.com sseigel@susmangodfrey.com Gary W. Jackson N.C. Bar No. 13976 THE LAW OFFICES OF JAMES SCOTT FARRIN, P.C. 280 South Mangum Street Suite 400 Durham, NC 27701 (919) 688-4991 Telephone (800) 716-7881 Facsimile gjackson@farrin.com Neal H. Weinfield THE DEDENDUM GROUP 1956 Cloverdale Ave. Highland Park, IL 60035 (312) 613-0800 Telephone (847) 478-0800 Facsimile nhw@dedendumgroup.com

IT IS SO ORDERED.

Attachment A

Absent a showing of good cause, a Party is only required to produce the metadata provided in the following fields applicable for the given produced document type, and in any event only insofar as such metadata is readily available, responsive, and not subject to the attorney-client privilege, work-product doctrine, or any other applicable privilege.

Field Definition Hard-Copy E-Document Scanned Image E-mail CUSTODIAN Name of person or other Yes Both data source (non-human) from where documents/files are produced. Where redundant names occur, individuals should be distinguished by an initial which is kept constant throughout productions (e.g., Smith, John A. and Smith, John B.) BEGBATES Beginning Bates Number Yes Both ENDBATES End Bates Number Yes Both PGCOUNT Number of pages in the No Both document FILESIZE File Size No Both APPLICAT Commonly associated No Both application for the specified file type FILENAME File name at collection No E-Document NATIVEFILELINK For documents provided in No E-Document native format TEXTPATH File path for OCR or Yes Both Extracted Text files MSGID Email system identifier No E-mail assigned by the host e-mail system. This value is extracted from parent message during processing Folder Folder location of the No E-mail e-mail within the PST/OST FROM Sender No E-mail TO Recipient No E-mail CC Additional Recipients No E-mail BCC Blind Additional Recipients No E-mail SUBJECT Subject line of e-mail No E-mail ATTACHBATES Bates number from the first No E-mail page of each attachment BEGATTACH Bates number of the first Yes E-mail page of the parent e-mail ENDATTACH Bates number of the last Yes E-mail page of the last attachment ATTACHCOUNT Number of attachments to No E-mail an e-mail ATTACHNAMES Names of each individual No E-mail Attachment, separated by semi-colons DATESENT Date Sent No E-mail (mm/dd/yyyy hh:mm:ss AM) DATERCVD Date Received No E-mail (mm/dd/yyyy hh:mm:ss AM) File Description System generated item No E-Document description, e.g., Word, email, calendar item, contact, note, task HASHVALUE MD5 or SHA-1 hash value No Both TITLE Title from within the No E-Document document AUTHOR Creator of a document No E-Document DATECRTD Creation Date No E-Document (mm/dd/yyyy hh:mm:ss AM) FSDATECRTD File system date created No E-Document LAST MODIFIED BY Last user who modified a No E-Document document LASTMODD Last Modified Date No E-Document (mm/dd/yyyy hh:mm:ss AM) FSLASTMODD File system date No E-Document modified Importance High Importance set for No E-mail e-mail Confidentiality Confidentiality level of Yes Both document in accordance with the Stipulated Protective Order Replacement Insert the word Yes Yes "Replacement" if the image is a replacement for a previously produced image; otherwise blank Redaction Insert the word "Redacted" Yes Yes if the document contains any redaction; otherwise blank Redaction Reason The reasons for redaction Yes Yes

The following fields should be included if de-duplication is used across custodian

OtherCustodians Custodians of unproduced No Both duplicate documents. Multiple values separated by semi-colons.
Source:  Leagle

Can't find what you're looking for?

Post a free question on our public forum.
Ask a Question
Search for lawyers by practice areas.
Find a Lawyer