Opinion
1:21-CV-01715-RA-OTW 1:17-CV-07954-RA-OTW
09-09-2022
CRAVATH, SWAINE & MOORE LLP, David M. Stuart Attorney for Plaintiffs LETITIA JAMES Attorney General of the State of New York by Andrew Blancato Assistant Attorney General, Attorney for Defendants
CRAVATH, SWAINE & MOORE LLP, David M. Stuart Attorney for Plaintiffs
LETITIA JAMES Attorney General of the State of New York by Andrew Blancato Assistant Attorney General, Attorney for Defendants
STIPULATION AND [PROPOSED] ORDER FOR THE PRODUCTION OF ELECTRONICALLY STORED INFORMATION AND OTHER DOCUMENTS
Ona T. Wang U.S.M.J.
The parties hereto, through their respective counsel of record, hereby stipulate to the following protocol governing the identification and production of electronically stored information (“ESI”) and other documents.
I. GENERAL PROVISIONS
A. Scope: The procedures and protocols set forth in this ESI Protocol shall govern the search, disclosure, and format of Documents and ESI produced for use in the above-captioned case. Except as specifically set forth herein, nothing in this stipulation is intended to alter any Producing Party, Receiving Party, or Requesting Party’s rights, obligations, or responsibilities under the Federal Rules of Civil Procedure or the Protective Order governing confidentiality entered in this matter. Nor does this Stipulation address, limit, affect, determine, or have any bearing on the relevance, discoverability, or admissibility as evidence of any information, regardless of whether the Document is to be preserved, is preserved, or is produced pursuant to the terms of this Stipulation. Nothing in this Protocol is intended to be an exhaustive list of discovery obligations or rights of a Producing Party or a Requesting Party. To the extent additional obligations or rights not addressed in this Protocol arise under the Federal Rules of Civil Procedure or the Protective Order governing confidentiality, they shall be controlling.
B. Definitions:
1. “Agreed Custodian” shall mean any individual of a Producing Party as identified and agreed by the parties during a meet and confer as having possession, custody, or control of potentially relevant information, Documents, or ESI.
2. “Document” shall have the meaning contemplated by Federal Rule of Civil Procedure 34(a)(1)(A).
3. “Document Family” means a collection of pages or files maintained together constituting a logical single communication of information but consisting of more than a single stand-alone record. Examples include a fax cover, the faxed letter, and an attachment to the letter-the fax cover being the “Parent,” and the letter and attachment being a “Child,” or an email and associated attachments, or a presentation with embedded files.
4. “Email” means an electronic means for communicating written information that is deliverable to designated recipients at specific addresses associated with particular Internet domains.
5. “ESI” is an abbreviation of “electronically stored information” and shall have the same meaning and scope as it has in Federal Rule of Civil Procedure 34(a)(1)(A).
6. “Extracted text” or “Full Text” means the text extracted from a Native Document, and includes all header, footer, and document body information when available. A “Text File” is a file containing the full text of native files extracted directly from the native file, or, in the case of Hard Copy Documents or scanned PDF documents, subject to OCR, a file containing the text resulting from the OCR.
7. “Hard Copy Document” means a Document that was maintained in paper form.
8. “Load File” means an electronic file that is used to import all required production information into a Document database, including, if available, Document images, Full Text, or OCR text, Native Format files where required by this ESI Protocol, and reasonably available Metadata, as well as information indicating Document breaks, and Document relationships such as those between an Email and its attachments. For files produced as TIFF images, each page of a Document shall be electronically saved as an image file. The Producing Party shall produce a unitization file, a type of load file, for all produced Documents in accordance with the specifications provided in Exhibit A.
9. “Metadata” means structured information about ESI that is created by the file system or application, embedded in the Document and sometimes modified through ordinary business use. Metadata of the ESI describes, inter alia, the characteristics, origins, usage, and validity of the ESI.
10. “Native Format” means the format of ESI in the application in which such ESI was originally created.
11. “OCR” means the optical character recognition technology used to read paper Documents or electronic images of Documents and output such Documents to a searchable text format. The latter text is also referred to as the “OCR text” or simply “OCR.”
12. “Production” or “Produced” includes any exchange of Documents or ESI by a Producing Party, whether voluntarily or in response to a formal or informal request.
13. “Producing Party” means any party or third party that produces Documents pursuant to this ESI Protocol.
14. “Receiving Party” means any party or third party that receives information, Documents, or ESI produced in the case.
15. “Requesting Party” means any party to the case that requests production of information, Documents, or ESI in the case.
16. “Responsive Document” means any Document or ESI that a Producing Party produces in response to any discovery request or subpoena served in or in connection with this case, subject to the limitations set forth in the Federal Rules of Civil Procedure or order entered by the Court.
17. “Tagged Image File Format” or “TIFF” refers to the CCITT Group IV graphic file format for storing bit-mapped images of ESI or Hard Copy Documents.
18. To avoid misunderstandings about terms, the parties should consult the most current version of the Sedona Conference Glossary.
C. Authenticity and Admissibility: Nothing in this ESI Protocol shall be construed to affect the authenticity or admissibility of any document or data. All objections to the authenticity or admissibility of any document or data are preserved and may be asserted at any time.
D. Confidential Information: For the avoidance of doubt, nothing herein shall contradict the parties’ rights and obligations with respect to any information designated as confidential under the parties’ agreed Protective Order.
E. Encryption: To maximize the security of information in transit, any media on which documents are produced may be encrypted by the Producing Party. In such cases, the Producing Party shall transmit the encryption key or password to the Requesting Party, under separate cover, contemporaneously with sending the encrypted media.
II. GENERAL PRODUCTION FORMAT
A. Initial Productions Only: The production specifications set forth below, including the specifications related to the parties’ privilege logs, apply to documents which are to be produced in the first instance in this action. To the extent any party is required to re-produce documents in this action that were originally produced in other actions, the parties have not agreed to reformat those earlier productions or prepare privilege logs for those earlier productions in accordance with the production specifications in this Order.
B. Format Guidelines: Other than as provided for in this stipulation, each Producing Party shall, to the extent reasonably and technically feasible, produce Documents and ESI according to the specifications provided in Exhibit A.
C. Processing Specifications: The Producing Party shall collect and process Documents using reasonable methods that preserve available data. To the extent reasonably feasible upon collection, the Producing Party shall use the following specifications when converting ESI from its Native Format into TIFF image files prior to production:
1. All tracked changes shall be maintained as last saved, to the extent reasonably feasible upon collection, so that all changes to a Document are evident, unless redactions were necessary to remove privileged material.
2. All Word Documents shall include and show field codes for auto-date and auto- time fields.
3. Author comments shall remain or be made visible, unless redactions were necessary.
4. Presenter notes within a presentation shall be made visible, to the extent reasonably feasible upon collection and unless redactions were necessary.
5. ESI shall be processed with a single time zone and date and time setting that is consistent across each Producing Party’s production (“Chosen Time Zone”). If a time zone other than UTC/GMT time zone is used for the Chosen Time Zone, a Producing Party shall notify the Requesting Party in the cover letter accompanying each production. The date and time reflected in the field in Exhibit A, and on any TIFF image will include the Chosen Time Zone. TIFF images may optionally show the local date and time if they display the offset to the Chosen Time Zone.
6. To the extent technically feasible, ESI items shall be processed in a manner that maintains and displays all hidden columns or rows, hidden text or worksheets, speaker notes, tracked changes and comments (i.e., shall force on hidden columns or rows, hidden work sheets, track changes, and comments). If the file ordinarily to be produced as a TIFF under this ESI Protocol cannot be expanded, the Receiving Party may request that the native be produced with the image file.
7. ESI items shall be processed so as to maintain the date/time shown in the Document as it was last saved by the custodian or end user, not the date of collection or processing (i.e., shall force off Auto Data).
8. If a Document otherwise subject to production in TIFF under this ESI Protocol cannot be converted to TIFF without error due to corruption or some other issue that renders the Document unreviewable, password protection, or some other issue, the Document shall be produced in Native format consistent with Section II(D) of this ESI Protocol.
D. Text Files: To the extent reasonably practicable, each Document produced under this ESI Protocol shall be accompanied by a single, multipage text file containing all of the text for that Document (as opposed to one text file per page of such Document). Each text file shall be named using the Bates Number of the first page of the corresponding production item.
1. ESI: The text of each ESI item shall be extracted directly from the ESI native file. To the extent that is not technically possible (e.g., the underlying native file is an image file), the text for each ESI item shall be generated by applying OCR to the native file under the provision above.
2. OCR: To the extent that Documents have been run through OCR software, the full text shall be provided on a document-level basis in an appropriately formatted text file (.txt) that is named to match the first Bates Number of the document. Text files shall be provided in a “Text” folder. To the extent that a Document is redacted, the text files shall not contain the text of the redacted portions, but shall indicate where the redactions were made, e.g. with the notation “REDACTED.” There is no obligation to OCR any electronic Documents that do not natively exist in a text-searchable format. The OCR software shall maximize text quality over process speed. Settings such as “auto-skewing” and “auto-rotation” should be turned on during the OCR process, to the extent reasonably practicable. If unitizing hard copy documents or providing OCR text presents an undue burden, or if the burden exceeds the benefit with respect to certain sets of hard copy documents, the Producing Party is not obligated to unitize and provide OCR text, but the Producing Party will disclose that fact to the Receiving Party.
E. Documents to Be Produced Natively: A Producing Party shall produce Microsoft Excel and other spreadsheet files, audio files, and video files in Native Format, if available. Other document types which may be difficult or costly to be accurately imaged, such as large Microsoft Power Point files, may be selected to be produced natively at the Producing Party’s discretion. The production load files shall contain a link to the produced Native Format files as specified in the “NativeLink” Metadata field described in Exhibit A. Each electronic file produced in Native Format shall be assigned a unique Bates Number as set forth in Section II(E), and the database record for that file shall include a single page TIFF image branded with this unique Bates Number, any confidentiality designation, and a standardized phrase indicating that the document was produced in native format (i.e., PRODUCED IN NATIVE FORMAT).
F. Bates Numbers and Confidentiality Designations for TIFF Images: Each page of a Document produced in the case in TIFF file format shall have a legible numeric identifier (“Bates Number”) electronically “burned” onto the image that must: (1) be unique across all Document productions in this case; (2) maintain a constant length and format of nine numeric digits (with a consistent prefix and including 0-padding to the same number of characters) across the entire production; (3) be sequential within a given document; and (4) include a letter prefix that can be readily attributed to the Producing Party followed by a singledash. The Bates Numbers shall be in a consistent font type and size. If a Bates number or set of Bates numbers is skipped in a production, the Producing Party will so note in a cover letter or production log accompanying the production. If warranted, consistent with the terms of the Protective Order, each page of a Document shall have either “CONFIDENTIAL” or “ATTORNEY’S EYES ONLY” electronically “burned” onto the image. The Producing Party will make reasonable efforts to avoid obscuring any information originally appearing on the document and will reproduce any such document on request.
G. Production Media:
1. The Producing Party shall produce Document images, Native Format files, Text and/or OCR files, Load Files, and Metadata on hard drives, CDs, DVDs, secure FTP, or other secure file transfer utility or other mutually agreeable media (“Production Media”). Production volumes may be produced via FTP or other electronic transfer system, without a separate agreement. Productions made via FTP or other electronic transfer are not required to be supplemented with hard media containing the same Documents. Each piece of hard media shall include a unique identifying label providing the identity of the Producing Party, the case number, the date of the production of Documents on the hard media, the disk number (1 of X, 2 of X, etc.) if applicable, Production Volume, and the Bates Number ranges of the Documents in the production. For productions delivered via a secure file transfer utility, the Producing Party shall provide a letter containing the information that would otherwise be on the label.
2. Each volume shall limit directory contents to approximately 5,000 files per folder. All productions shall be checked and produced free of computer viruses. To the extent that the Production Media includes any confidential information protected under any applicable Protective Order, the label on such Production Media shall indicate that the Production Media includes information so designated. Further, any replacement Production Media shall cross-reference the original Production Media, clearly identify that it is a replacement, and cross-reference the Bates Number range that is being replaced. All Production Media that is capable of write protection should be write-protected before production.
3. All Production Media may be encrypted, with the Producing Party to provide a decryption key at the time of production.
III. ESI METADATA FORMAT AND PROCESSING ISSUES
A. System Files: ESI productions may be de-NISTed using the industry standard list of such files maintained in the National Software Reference Library by the National Institute of Standards & Technology as it exists at the time of deNISTing. Other file types may be added to the list of excluded files by agreement between the parties.
B. Metadata Fields and Processing: A Producing Party is not obligated to populate manually any of the fields in Exhibit A, with the exception of the following, which must always be populated for ESI: (a) BegBates, (b) EndBates, and (c) Custodian. To the extent the fields can be automatically populated at the time of production, Production Volume and SourceParty shall be populated. Additionally, the Producing Party must populate the following fields in Exhibit A if applicable and reasonably and technically possible: (a) Confidentiality, (b) PageCount, (c) AllCustodian (which is required if performing horizontal deduplication pursuant to Section III(E)), and (d) Redacted and (e) family designation fields sufficient to identify all members of a Document Family (e.g., BegAttach and EndAttach, and AttachmentCount). To the extent reasonably available, Metadata identified in Exhibit A shall be provided in a Concordanceformat delimited file with a .DAT file extension using Concordance default delimiters, including ASCII 020 and 254 delimiters for column break and text qualifier, and new line as ASCII 13 and ASCII 10. The first line shall be the header with field names, and each subsequent line shall contain the fielded data for each Document.
C. Redacted Documents: For any Document that is redacted (in whole or in part), the full text may be replaced with OCR text that excludes the redacted material, Metadata fields may be redacted if they contain redactable information, and the Native Format version need not be produced. When a Document is redacted, 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 requires redaction, that Document may be produced in redacted TIFF format, or in redacted Native Format, at the Producing Party’s discretion, and to the extent reasonably and technically possible.
D. Email Thread Suppression: Email threads are email communications that contain prior or lesser-included email communications. A most inclusive email thread is one that contains all of the prior or lesser-included emails and attachments, including each branch of the email thread. A Producing Party may use e-mail thread suppression to exclude email from production, provided however, that an email that includes an attachment or content in the BCC or other blind copy field shall not be treated as a lesser-included version of an email that does not include the attachment or content, even if all remaining content in the email is identical.
E. De-Duplication: The Producing Party need only produce a single copy of a particular electronic Document.
1. A Producing Party may de-duplicate any file globally (i.e., across Document Custodians) or horizontally at the “family” level. Attachments should not be eliminated as duplicates for purposes of production, unless the parent email and all attachments are also duplicates. Parties agree that an email that includes content in the BCC or other blind copy field shall not be treated as a duplicate of an email that does not include content in those fields, even if all remaining content in the email is identical. In the event of rolling productions of documents or ESI items, the Producing Party will, as needed, supplement the load files with updated AllCustodian information. Duplicate custodian information may be provided by a metadata “overlay” and will be provided by a Producing Party after the Party has substantially completed its production of ESI.
2. If a Producing Party elects to de-duplicate, the Producing Party shall identify ESI duplicates by using industry standard MD5 or SHA-1 algorithms (or a reasonably equivalent alternative) to create and compare hash values for exact duplicates only. Other methodologies that are substantially different for identification of duplicates must be discussed with the Requesting Party and approved in writing before implementation. The resulting hash value for each item shall be reflected in the HASH Value field specified in Exhibit A.
F. Attachments: Email attachments and embedded files must be mapped to their parent Document by the Bates Number by including a “BegAttach” field designating the beginning of each such attachment and “EndAttach” field designating the end of each such attachment. If attachments and embedded files cannot be separated from their parent Documents, then “BegAttach” and “EndAttach” fields listing the unique beginning and end number for each attachment or embedded Document must be included. Non-substantive automatically-generated embedded files, such as logos, embedded, nonsubstantive formatting files such as .ole or .dll formats, or confidentiality legends need not be produced as separate attachments. To the extent they are maintained together, all Documents in a Document Family shall be consecutively Bates Number stamped with the child Documents produced immediately after the parent-document.
G. Compressed and Container Files: Compression file types (e.g., .CAB, .GZ, RAR, .ZIP), shall be decompressed to ensure that a compressed file within a compressed file are decompressed into the lowest possible compression resulting in individual folders and/or files. Original compression files and container files need not be produced, provided the responsive content files are produced in accordance with the specifications of this ESI Protocol.
H. Custodian or Originating Source: The custodian or originating source shall be identified in the Custodian field of the database load files, as provided in Exhibit A. Documents found in the possession of a natural person (or on a natural person’s hardware or storage media) shall be produced in such fashion as to identify the natural person. A Producing Party shall use a uniform description of a particular Agreed Custodian or originating source across productions.
IV. PAPER DOCUMENT PRODUCTION ISSUES
A. Unitization: In scanning Hard Copy Documents, distinct Documents shall not be merged into a single record, and single Documents shall not be split into multiple records. The Producing Party shall take reasonable steps to physically and logically unitize Hard Copy Documents. For example, Documents stored in a binder, folder, or similar container (each, a “container”) shall be produced in the same order as they appear in the container. Similarly, pages that are stapled or clipped shall be produced as a single document and not multiple one-page documents. The Producing Party shall undertake reasonable efforts to, or have its vendors, logically unitize (i.e., use cues such as consecutive numbering, report titles, similar headers and footers, and other logical cues that indicate the pages belong together) Hard Copy Documents that are not otherwise bound. The Producing Party shall make reasonable best efforts to unitize Hard Copy Documents correctly. This provision does not obligate any Producing Party to reassemble Document Families for Hard Copy Documents that are not stored or maintained as Document Families in the location in which members of that family are found or as they are kept in the ordinary course of business. Nor shall this provision obligate any Producing Party to make whole any Document that is not stored or maintained in its complete form.
V. DATABASE AND OTHER NON-STANDARD FILE TYPES: The parties shall agree, on a file-specific or file type-specific basis, as to the production format for databases and other non-standard file types not specifically addressed above. Nothing herein shall limit or affect a party’s rights or obligations with regard to the ESI file types specifically addressed in the provisions above.
VI. ASSERTIONS OF PRIVILEGE AND REDACTIONS
A. Waiver: Protection against waiver of privilege or other protection from discovery shall be governed by the Stipulated Protective Order. The parties do not waive the right to conduct a full and comprehensive review for privilege and other protections.
B. Production of Privilege Logs: Except as provided otherwise below, for any document withheld in its entirety or produced but redacted, the Producing Party will produce privilege/redaction logs in MS Excel format or any other format that permits electronic sorting and searching.
C. Privilege Log Requirements:
1. Communications involving case counsel (both outside counsel and inhouse counsel responsible for the case, including their staff or consultants) need not be placed on a privilege log.
2. If a party redacts a document, the accompanying metadata should so indicate. The parties will use reasonable best efforts to provide their privilege logs on a rolling basis. In any event, the parties will provide a substantial portion of the privilege logs no later than 14 days before the close of the discovery period.
3. Privilege logs shall contain the following information for each Responsive Document or ESI withheld or redacted:
a. a sequential number associated with each privilege log record;
b. the date of the Document or ESI;
c. the Bates Numbers of Documents or ESI redacted or a numerical or other identifier for each Document or ESI withheld;
d. the identity of persons who sent (and, if different, the identity of all persons who authored or signed) the Document or ESI and the addressees, recipients, copyees, and blind copyees (with senders, signers, authors, addressees/recipients, copyees, and blind copyees, each separately identified by those categories), and identification of which of them are attorneys;
e. a description of the subject matter of the information contained in the Document or ESI that, without revealing information itself privileged or protected, is sufficient to understand the subject matter of the Document and the basis of the claim of privilege or immunity. To the extent the name of the attorney it is not otherwise identified, it shall be included in the description, to the extent ascertainable from the document. The same description may be used for multiple Documents (i.e., a categorical description) so long as the Producing Party has, in good faith, evaluated the Document to ensure the categorical description accurately reflects the contents of the Document and is sufficient for the Receiving Party to evaluate the claim of privilege or immunity;
f. the type or nature of the privilege asserted (i.e., attorney-client privilege or work product doctrine, and if such other privilege or immunity is asserted it shall be separately identified along with identification of whether the Producing Party or some other entity
holds the privilege or protection asserted); and
g. an indication of whether the Document or ESI has been redacted and produced or withheld in its entirety.
The parties reserve the right to discuss other methods of logging data if the procedures described in this ESI protocol impose an undue burden.
D. Metadata for Privilege Log: To the extent applicable, each party’s privilege log may rely on objective metadata (to the extent it is reasonably available) to satisfy requirements IV.C.3.a through IV.C.3.d, supra.
E. Challenges to Privilege Claims: Following receipt of a privilege/redaction log, a Requesting Party may identify, in writing (by Bates/unique identified number), the particular document(s) that it believes require further explanation. The Producing Party shall endeavor to respond to such a request within 14 days. If a party challenges a request for further information, the parties shall meet and confer to try to reach a mutually agreeable solution. If they cannot agree, the matter may be brought to the Court.
F. “Relevancy” Redactions: A party may redact irrelevant information that is highly sensitive, medical, or personal information (e.g., health information or Social Security Numbers).
VII. AMENDMENT OF ORDER
A. Nothing in this ESI Protocol waives the right of the parties to seek a Stipulated Order or any Producing Party to petition the Court for an Order modifying the terms of this ESI Protocol upon sufficient demonstration that compliance with such terms is either (1) unexpectedly or unreasonably burdensome, or (2) impossible, provided, however, that counsel for such Producing Party must first meet and confer with counsel for the Requesting Party, and the Requesting Party and Producing Party shall use reasonable best efforts to negotiate an exception from or modification to this ESI Protocol prior to seeking relief from the Court.
SO ORDERED.
EXHIBIT A
1. COVER LETTER
A cover letter shall be included with each production and shall include information sufficient to identify all accompanying media (hard drive, thumb drive, DVD, CD, secure FTP), shall identify each production on such media by assigning a Production Volume name or number, and shall include the Bates range for the Documents produced in each volume.
2. PRODUCTION LOAD FILES
There will be two Load/Unitization files accompanying all Productions of ESI.
The first will be a Metadata import file, in Concordance-format delimited file with a .DAT file extension, that contains the agreed upon Metadata fields in UTF-8 encoding.
The second will be a cross-reference file that contains the corresponding image information identifying document breaks. The acceptable formats for the cross-reference files are .log and .opt.
• Image Load Files
1. The name of the image load file shall mirror the name of the delivery volume, and shall have the appropriate extension (e.g., ABC001.OPT).
2. The volume names shall be consecutive (e.g., ABC001, ABC002, et seq.).
3. There shall be one row in the load file for every TIFF image in the Production.
4. Every image in the delivery volume shall be cross-referenced in the image load file.
5. The imageID key shall be named the same as the Bates Number of the page.
6. Load files shall not span across media (e.g., CDs, DVDs, hard drives, etc.), i.e., a separate volume shall be created for each piece of media delivered.
7. Files that are the first page of a logical Document shall include a “Y”
where appropriate. Subsequent pages of all Documents (regular Document, Email, or attachment) shall include a blank in the appropriate position.
• Concordance Data Load Files:
1. Data load files shall be produced in .DAT format.
2. The data load file shall use standard Concordance delimiters:
3. Comma - ¶ (ASCII 20);
4. Quote - 6 (ASCII 254);
5. Newline - ® (ASCII 13 and ASCII 10).
6. The first line of the .DAT file shall contain the field names arranged in the same order as the data is arranged in subsequent lines.
7. All date fields shall be produced in mm/dd/yyyy format.
8. All attachments shall sequentially follow the parent document/email.
9. Use carriage-return to indicate the start of the next record.
10. Load files shall not span across media (e.g., CDs, DVDs, hard drives, etc.); a separate volume shall be created for each piece of media delivered.
11. The name of the data load file shall mirror the name of the delivery volume, and shall have a .DAT extension (e.g., ABC001.DAT).
12. The volume names shall be consecutive (e.g., ABC001, ABC002, et seq.).
13. If foreign language / Unicode text exists, the .DAT file shall be in UTF-8 or UTF-16 format where appropriate, consistent with this ESI Protocol.
• OCR/Extracted Text Files
1. OCR or Extracted Text files shall be provided in a separate \TEXT\ directory containing Document level text files.
3. IMAGES
Produce Documents in Single Page Group IV TIFF black and white files. Image Resolution of 300 DPI. Paper size shall be 8.5 x 11 inches unless in the reasonable judgment of the Producing Party, a particular item requires a different page size.
If a Receiving Party reasonably deems the quality of the Document produced in TIFF format to be insufficient, the parties will meet and confer in good faith to determine whether the Producing Party must produce the Document in Native Format, or as a JPEG file, and whether such Document must be produced as a color image.
If a Receiving Party reasonably believes that a Document originally produced in black and white needs to be produced in color, it shall notify the Producing Party. The parties agree to meet and confer in good faith concerning the re-production of such Document(s) in color either as a JPEG file or in Native Format.
File Naming Convention: Match Bates Number of the page.
Original Document orientation or corrected orientation shall be retained.
4. ESI (AND PAPER TO THE EXTENT APPLICABLE) PRODUCTION METADATA FIELDS
Field Name | Description |
BegBates | Beginning Bates Number. |
EndBates | Ending Bates Number. |
BegAttach | Beginning Bates Number of the first Document in a Document family range. Documents that are part of Document families, i.e., containing parents and attachments, should receive a value. |
EndAttach | Ending Bates number of the last Document in attachment range in a Document Family range. Documents that are part of Document Families, i.e., containing parents or attachments, should receive a value. |
AttachmentCount | Populated for Email parent records and indicates the number of attachments that constitute the whole family (BegAttach to EndAttach) |
Custodian | Name of the Custodian of the Document Produced or originating source, to the extent reasonably and technically available. |
AllCustodian | The AllCustodian field shall reference the Name(s) of all Custodian(s) who were in possession of a de-duplicated Document pursuant to Section III(E). |
FileName | Filename of the original source ESI. |
NativeLink | Path and filename to produced Native Format file (see Section II(D)). |
EmailSubject | Subject line extracted from an Email. |
Field Name | Description |
Title | Title field extracted from the Metadata of a non-Email. |
Author | Author field extracted from the Metadata of a non-Email. |
From | From or Sender field extracted from an Email. |
To | To or Recipient field extracted from an Email. |
CC | CC or Carbon Copy field extracted from an Email. |
BCC | BCC or Blind Carbon Copy field extracted from an Email. |
DateSent | Sent date of an Email (mm/dd/yyyy format). |
TimeSent | Time of an Email (hh:mm:ss format). |
DateReceived | Received date of an Email (mm/dd/yyyy format). |
TimeReceived | Received time of an Email (hh:mm:ss format). |
DateCreated | Creation date of a file (mm/dd/yyyy format). |
TimeCreated | Creation time of a file (hh:mm:ss format). |
DateLastModified | Last modification date (mm/dd/yyyy format). |
TimeLastModified | Last modification time (hh:mm:ss format). |
DateLastPrinted | The date the Document was last printed. |
DateAccessed | The last accessed date of the Document. |
File Extension | File extension of Document (.msg, .doc, .xls, etc.). |
Full Text | File path to full text/OCR File. |
Confidentiality | “Confidential” or “Highly Confidential,” if a Document has been so designated under any Stipulated Protective Order filed with the Court; otherwise, blank. |
Message-ID | The Outlook Message ID assigned by the Outlook mail server, if applicable |
Field Name | Description |
Conversationindex | Unique alphanumeric identifier for an email conversation, which may be populated by the e-mail client for each outgoing message. |
HASHValue | MD5 or SHA Hash value of the file. |
FolderPath | The path to the original folder in which the Document was located. |
FileSize (in bytes) | Size of the file in bytes. |
PageCount | The number of pages in the file. |
AttachRange | Bates Number of the first page of the parent item to the Bates Number of the last page of the last attachment “child” item. |
Application | Indicates software application that generated the ESI item (e.g., Outlook, Word). |
Production Volume | Production volume name or number. |
Redacted | User-generated field that will indicate redactions. “X,” “Y,” “Yes,” “True,” are all acceptable indicators that the Document is redacted. Otherwise, blank. |
SourceParty | The Producing Party. |
Time Zone | Chosen Time Zone |