STIPULATION AND ORDER REGARDING THE PRODUCTION OF ELECTRONICALLY STORED INFORMATION AND HARD COPY DOCUMENTS
DONALD G. WILKERSON, Magistrate Judge.
THIS MATTER having been presented to the Court on consent of the parties, and for good cause shown;
IT IS ON THIS 6th day of September, 2017;
ORDERED that all parties' productions in this matter shall be in accordance with the following protocol:
I. GENERAL PROVISIONS AND SCOPE:
A. The Order streamlines ESI production to promote a "just, speedy, and inexpensive determination" of this action, as required by Rule 1 of the Federal Rules of Civil Procedure. The procedures and protocols set forth in this Order shall govern the production format of hard-copy documents and ESI in this action, to the extent available. The Parties reserve all rights and objections under the Federal Rules of Civil Procedure for matters relating to the production of ESI or hard-copy documents that are not specifically addressed in this Order.
B. This Order may be modified for good cause. The Parties may agree to modification without application to the Court. To be effective any modification must be in writing and signed by counsel for both Parties. If the Parties cannot reach an agreement regarding proposed modifications, the Parties shall submit their competing proposals and a summary of their dispute to the Court, or comply with any other procedure ordered by the Court.
II. PRESERVATION AND COLLECTION:
A. The Parties acknowledge their ongoing responsibility to preserve potentially responsive ESI and hard-copy documents, and they agree that the preservation of potentially relevant ESI and hard-copy documents will be reasonable.
B. There is no need to preserve or collect ESI from the following sources, which are deemed not likely to contain relevant information and not to be reasonably accessible:
1. Random access memory (RAM), temporary files, or other ephemeral data that are difficult to preserve without disabling the operating system;
2. On-line access data such as temporary internet files, history, cache, cookies, and the like;
3. Voice-mail messages; imessages, text messages and similar ephemeral data on personal devices that no longer exist on such devices;
4. Back-up data that is substantially duplicative of data that are more easily accessible elsewhere;
5. Server, system, or network logs; and
6. Data remaining from systems no longer in use that are unintelligible on the systems in use.
C. No Party is obligated to preserve hardware on which data that is required to be preserved resides, so long as such data and associated metadata has first been imaged or otherwise preserved in an accessible form on another hardware device.
D. The Parties shall preserve e-mail communications, including all associated metadata and associated attachments relevant to claims or defenses in this action (1) by maintaining such e-mail files on a server or within an electronic archive that is not subject to a deletion schedule, or (2) by creating an electronic snapshot of implicated e-mail on servers.
E. The Parties shall preserve data relevant to claims or defenses and held in databases (1) by maintaining such data in accessible electronic systems that are not subject to a deletion schedule, or (2) by creating an electronic snapshot of relevant database servers or an export of relevant data on database servers.
F. Where electronic documents relevant to claims or defenses in this action and located in shared or home directories (e.g., loose files such as word-processing documents, Excel spreadsheets, and PowerPoint presentations) are subject to a deletion schedule, the Parties shall preserve such documents by (1) maintaining such directories and files contained therein in accessible electronic systems that are not subject to a deletion schedule, or (2) by creating a forensically sound backup of relevant shared drive or home directory servers.
III. PRODUCTION OF HARD-COPY DOCUMENTS
The format of productions of hard-copy documents shall comply with the following requirements:
A. IMAGE FORMAT. Documents that exist in hard-copy format shall be scanned and produced as single page black and white PDF files or Group IV TIFFs created with a resolution of at least 300 dots per inch ("dpi"). Color documents may in .JPG format in lieu of TIFF images; color .JPG files shall also be provided with a resolution of at least 300 dpi. Each TIFF or .JPG image shall be branded with sequential production number and appropriate confidentiality designations. Each TIFF or .JPG image filename shall correspond to the Bates number associated with that page. TIFF or .JPG files shall show all text and images that would be visible to a user of the hard-copy document. Producing such hard-copy documents in such formats does not change their character from hard-copy documents into ESI.
B. DATABASE LOAD FILES/CROSS-REFERENCE FILES. A production should be provided with (a) an ASCII delimited data file (".dat") using Concordance default delimiters, and (b) an Opticon (Concordance Image) image load file (".opt") that can be loaded into Concordance version 8 or above. In addition:
1. The total number of documents referenced in a production's data load file should match the total number of designated document breaks in the Image Load file(s) in the production.
2. The Opticon file should provide the beginning and ending Bates number of each document and number of pages it comprises. Each TIFF in a production must be referenced in the corresponding image load file.
3. In addition to the metadata fields identified for production in Section IV.C below, each .dat file shall include links to multi-page (document level) text files ("Text Path").
C. OCR TEXT FILES. A commercially acceptable technology for optical character recognition ("OCR") shall be used for all scanned, hard-copy documents. The filename for the multipage text file described above in Section III.B.3 shall correspond to the beginning Bates number of the document. If the document is redacted, the text file shall not contain the redacted portions of the documents, but shall contain the remaining unredacted text.
D. METADATA. The following fields, which are defined in Appendix A, shall be produced in the .dat file accompanying hard-copy documents: (a) BEGBATES, (b) ENDBATES, (c) BEGATTACH, (d) ENDATTACH, (e) PAGE COUNT, (f) CUSTODIAN, (g) RECORD TYPE, (h) CONFIDENTIAL DESIG, and (i) REDACTION.
E. UNITIZING OF DOCUMENTS. In hard-copy documents, distinct documents shall not be merged into a single record, and single documents shall be not be split into multiple records (i.e., hard-copy documents should be logically unitized). The Parties shall use reasonable efforts to unitize documents correctly to avoid producing large numbers of documents in a single "clump."
IV. PRODUCTION OF ESI:
A. FILTERING.
1. Electronic file collections will be De-NISTed, removing commercially available operating system and application file information contained on the current NIST file list. Additional filtering of system file types based on file extension may include, but are not limited to: WINNT, LOGS, DRVS, C++ Program File (c), C++ Builder 6 (cpp), Channel Definition Format (cdf), Creatures Object Sources (cos), Dictionary file (dic), Executable (exe), Hypertext Cascading Style Sheet (css), JavaScript Source Code (js), Label Pro Data File (IPD), Office Data File (NICK), Office Profile Settings (ops), Outlook Rules Wizard File (rwz), Scrap Object, System File (dll), Temporary File (tmp), Windows Error Dump (dmp), Windows Media Player Skin Package (wmz), Windows NT/2000 Event View Log file (evt), Python Script files (.py, .pyc, .pud, .pyw), and Program Installers.
2. The Parties shall filter out stand-alone files identified as zero-bytes in size.
3. The Parties may limit processing of discoverable information to that which was created, modified, sent, or received between certain dates as agreed by the Parties, or set forth by the Court. Container files such as (.zip, .rar or .tar files) will be processed such that their contents may be reviewed individually.
B. STRUCTURED DATA.
Data that is stored in a database, whether maintained internally by the Party or through a third party provider, shall, when reasonably possible, be produced as reports in Microsoft Excel, Microsoft Access or ASCII delimited text format.
C. PRODUCTION FORMAT FOR ESI.
1. Image Format. With the exception of the documents discussed in section IV.C.6 below, all ESI documents shall be produced as single page black and white Group IV TIFFs, created with a resolution of at least 300 dpi. Color documents may be produced in .JPG format in lieu of TIFF images color .JPG files should also be provided with a resolution of at least 300 dpi. Each TIFF or .JPG image shall be branded with sequential production numbers and appropriate confidentiality designations. Each TIFF or .JPG image filename shall correspond to the Bates number associated with that page. TIFF or .JPG files shall show all text and images that would be visible to a user of the ESI documents in native format. Thus, for example notes and redlines or comparisons in documents (i.e., Microsoft Word notes and redlines) shall be processed with all markings and hidden text unhidden and to show the author for the edits and comments on the TIFF of .JPG image.
2. Numbering/Endorsement. Every produced document will have a unique Bates number assigned, regardless of the format of the documents. The Bates number prefix will be generated so as to identify the producing party. For documents produced in TIF image format, including slipsheet images for natively-produced files, each TIFF image will have a legible Bates number as a unique page identifier electronically "burned" onto the image at a location that does not obliterate or obscure any information from the source document. Files produced in native format shall be named by corresponding Bates number with confidentiality designation (e.g., BATES00000010_CONFIDENTAL.xlsx); if the file does not have a confidentiality designation then only the bates number needs to be used (e.g., BATES00000010.xlsx) . A producing party should be consistent in the Bates number prefixes it uses across its productions. Document families shall be produced consecutively, noting family relationships in the appropriate metadata fields. In the case of materials deemed confidential in accordance with any applicable federal, state, or common law, or any protective order or confidentiality stipulation entered into by the Parties, a confidentiality designation may be "burned" onto the document's image at a location that does not obliterate or obscure any information from the source document.
3. Metadata. For email, the Parties shall provide the applicable email metadata fields outlined in Appendix A hereto and associated with each document produced, to the extent they are reasonably available from the source of collection. For email attachments and non-email electronic documents (standalone, loose native files), the Parties shall provide the applicable non-email ESI metadata fields outlined in Appendix A hereto and associated with each electronic document produced, to the extent they are reasonably available from the source of collection. For hard copy documents, the Parties shall provide the applicable metadata fields associated with hard copy outlined in Appendix A. All metadata referenced in Appendix A shall be provided in a delimited (.dat) file with the field headers as the first row.
Format of .dat file delimeters:
Column — ASCII 020
Quote — ASCII 254
Newline — ASCII 174
Multi-Value — ASCII 059
4. Image Cross Reference. A standard Opticon (.OPT) file will be provided with each production that contains document boundaries.
a) Format:
<Bates Number>,<Volume Name>,<Relative Path to TIF Image>,<Y if First Page of Document,
Else Blank>,,,<If First Page of Document, Total Page Count>
b) Example:
BATES000000001,VOL001,\IMAGES\001\BATES00000001.TIF,Y,,,,2
BATES000000002, VOL001,\IMAGES\001\BATES00000002.TIF,Y,,,,
BATES000000003, VOL001,\IMAGES\001\BATES00000003.TIF,Y,,,,1
5. Text. Document level text files (.TXT) will be provided for each document produced. Text files will be named the first Bates number of the respective document. Extracted text will be provided when it exists for non-redacted documents. OCR Text will be provided for documents when no extracted text exists or when the document is redacted.
6. Native Files. Subject to section VIII below regarding redactions, any file produced in native format should be produced with a link in the Nativelink field, along with extracted full text and all applicable and reasonably available metadata fields set forth in Appendix A to the extent doing so is feasible. Any file produced in native format should be named to match the beginning Bates number of their corresponding entries in the database load files. Additionally, every file produced natively should be accompanied by a Bates-stamped and confidentiality-stamped TIFF placeholder indicating the document was provided in native format.
a) Spreadsheets. Spreadsheets shall be produced in native format, with TIFF placeholders and available metadata provided in database load files, unless they are redacted, in which case they shall be produced as TIFF images. In addition to the requirements laid out in section IV.C.6 above, native copies of all spreadsheets (unless redacted) shall be produced with extracted full text and all applicable and reasonably available metadata fields set forth in Appendix A.
b) Presentation Files. Presentations shall be produced in native format, with TIFF placeholders and available metadata provided in database load files, unless they are redacted, in which case they shall be produced as TIFF images. In addition to the requirements laid out in section IV.C.6 above, native copies of all presentations (unless redacted) shall be produced with extracted full text and all applicable and reasonably available metadata fields set forth in Appendix A.
c) Video & Audio Files. Audio and Video files shall be produced in native format, with TIFF placeholders and available metadata provided in database load files.
d) Request for Additional Native Files. If a Party reasonably concludes that production in native format of any document(s) is necessary (e.g., to decipher the complete meaning, context, or content; to determine if there is any relevant "hidden text" in the document; to determine if there is any important use of color in the document, etc.), such Party may request production of the original document in native format, which request shall not unreasonably be denied. The Parties agree to meet and confer in good faith with respect to any such request. The producing Party may decide that a reasonable basis exists to produce additional file types among its own collection in native format and may do so after notifying the receiving Party. Any native files that are produced should be produced with a link in the Nativelink field, along with all extracted text and applicable metadata fields, as well as a Bates-stamped and confidentiality-stamped TIFF placeholder.
D. PRESUMPTION OF AUTHENTICITY: The Parties agree, without waiving any other objections as to admissibility, that all ESI produced in discovery by the Parties are presumed to be authentic for purposes of this lawsuit only, absent a showing that the document is not what the proponent claims it to be.
V. THIRD PARTIES:
A. A party that issues a non-party subpoena (the "Issuing Party") shall include a copy of the Order with the subpoena and request that third parties produce data and documents in accordance with the specifications set forth herein.
B. Nothing in the Order is intended or should be interpreted as narrowing, expanding, or otherwise affecting the rights of third parties to object to a subpoena.
C. The Issuing Party is responsible for producing any documents obtained under a subpoena to the other party.
D. If the Issuing Party receives any hard-copy documents or native files, the Issuing Party will process the documents in accordance with the provisions of the Order, and then produce the processed documents to the other party.
E. If the non-party production is not Bates-stamped, the Issuing Party will apply unique prefixes for the non-party production and Bates numbers prior to producing them to all the other Parties.
VI. PRODUCTION MEDIA:
The production data may be exchanged between counsel in encrypted form (e.g., TrueCrypt, password-protected Zip, or RAR files). Productions of 10 or fewer GB may be made via FTP or secure server; larger productions should be made on hard media (e.g., hard drives). Each production shall be provided in the following folder structure:
A. Top-level folder: This folder will indicate the production volume;
B. Sub folders;
1. IMAGES: This folder will contain multiple sub-folders with only TIFF and.JPG files in them. No other type of file should reside in the "IMAGES" folder. Sub-folders shall not contain more than 5,000 images per folder.
2. TEXT: This folder will contain the full text files in UNICODE, UTF8 or ANSI format in a separate folder labeled TEXT. Subfolders shall not contain more than 1,000 text files per folder.
3. DATA: This folder will contain load files compatible with Concordance version 8 or above and Opticon.
4. NATIVES: This folder will contain native files. Sub-folders shall not contain more than 1000 native files per folder.
VII. PRIVILEGE:
A. The Parties shall produce privilege logs following each production. The privilege logs shall contain the following information:
1. Bates Begin;
2. Bates End;
3. Bates Begin Attach;
4. Bates End Attach;
5. Custodian;
6. Privilege Claim (e.g., WP, AC);
7. Email To;
8. Email From;
9. Email CC;
10. Email BCC;
11. Date Sent or Date Created; and
12. Description of Nature of Document.
B. The Parties shall identify on their logs where counsel is present in conversation, specifically for columns A(7) through A(10) noted above. Where the presence of counsel forming the basis of the privilege is not readily ascertainable from columns A(7) through A(10) above, the Parties shall include a reference to counsel in the description filed described in A(12) above.
C. Privileged communications between Parties and their counsel regarding the above captioned actions, including any pre-complaint investigation need not be placed on a privilege log. The Parties may agree to other communications that need not be logged.
D. With respect to email chains (i.e., documents that reflect multiple, distinct emails), the Parties agree that: (i) the Parties will not withhold from production non-privileged, substantive portions of email strings; (ii) the Parties' privilege logs need not contain separate log lines for individual emails within a single email chain that is logged; and (iii) the Parties' privilege logs need not contain separate log lines for emails that are otherwise logged as part of an email chain.
VIII. REDACTIONS:
A. REDACTIONS. In the event that a document or ESI requires redaction the Parties agree that the native version need not be produced in the first instance, full text may be replaced with OCR text that excludes the redacted material, and metadata fields may be excluded if they contain material redacted for privilege. The TIFF image should show the word "redacted" where applicable and a production Load File field should be populated to indicate the document contains a redaction. If a document to be produced in native format contains information that would otherwise be subject to redaction — e.g., on the basis of privilege or work product protection — the document may be produced by producing the document either in redacted and/or excerpted TIFF format, or in redacted and/or excerpted native format, in the producing Party's discretion, and to the extent reasonably and technically possible. If a Party reasonably concludes that production in native format of any redacted document(s) initially produced in TIFF format is necessary (e.g., to make the a document, including any spreadsheet of presentation readable, to decipher the complete meaning, context, or content, to determine if there is any relevant "hidden text" in the document, to determine if there is any important use of color in the document, etc.), such Party may request, with the understanding that relevant portions of native files to be replaced with "[REDACTED]" or a similar mark as necessary, the production of the original document in native format, which request shall not unreasonably be denied. The Parties agree to meet and confer in good faith with respect to any such request.
IX. DISPUTE RESOLUTION:
The parties shall meet and confer in good faith on any issue related to ESI or hard-copy document discovery prior to submitting any dispute to the Court.
IT IS SO ORDERED.
Attachment
Hard
Field Description Email Or Loose
Copy
Native File
BEGBATES First bates number assigned to X X X
the first page of the document
ENDBATES Last bates number assigned to X X X
the last page of the document
BEGATTACH First bates number assigned to X X
the first document in a family
ENDATTACH Last bates number assigned to X X
the last document in a family
PAGE COUNT Number of images provided X X X
for the document
Individual/Source assigned to
CUSTODIAN X X X
the record at collection time,
formatted as Last Name First
TITLE Native file property Title X
SUBJECT Native file property Subject X
DATE Date created as extracted from
CREATED original file (MM/DD/YYYY) X
TIME CREATED Time created as extracted X
from original file (24 HR)
DATE LAST Date last modified as
extracted from original file X
MODIFIED (MM/DD/YYYY)
[Normalized to GMT]
TIME LAST Time last modified as
X
MODIFIED extracted from original file
(24 HR) [Normalized to
Type of file (e.g. EMAIL
RECORD TYPE ITEM, ATTACHMENT, X X X
LOOSE FILE, E-DOC,
FILE NAME Name of file as it appeared X
when collected.
FILE Extension of the native file. X
EXTENSION
FILE SIZE Size of the native file, in bytes X
Original folder path to file
FOLDER PATH when collected (if loose native X
file) or folder path to
EMAIL FROM Email FROM value (Email X
Author)
EMAIL CC Email CC value (Email X
Copyee)
EMAIL BCC Email BCC value (Email X
Blind Copyee)
EMAIL TO Email TO value (Email X
Author)
EMAIL DATE Date email sent X
SENT (MM/DD/YYYY)
EMAIL TIME Time email sent (24 HR) X
SENT [Normalized to GMT]
EMAIL DATE Date email received X
RECEIVED (MM/DD/YYYY)
EMAIL TIME Time email received (24 HR) X
RECEIVED [Normalized to GMT]
EMAIL Email Subject value X
SUBJECT
Relative path to the document
level text file (e.g.
TEXT LINK X X X
\TEXT\001\BATES00000000
1.TXT)
Relative path to native file (if
produced). (.e.g.
NATIVE LINK X
\NATIVES\001\BATES00000
0001.XLS)
MD5_HASH MD5 hash value of native file X X
CONFIDENTIAL Confidentiality designation X X X
DESIG
REDACTION Yes/No field indicating X X X
whether or not document is
