Opinion
4:21-cv-00095-CDL
12-27-2021
AMERICAN SOUTHERN HOMES HOLDINGS, LLC AND ASH-GRAYHAWK, LLC, Plaintiffs, v. DAVID B. ERICKSON, et al., Defendants.
CONSENT ORDER REGARDING THE PRODUCTION OF ELECTRONICALLY STORED INFORMATION (“ESI”) AND HARD COPY DOCUMENTS
CLAY D. LAND, United States District Judge.
Before the Court is the Stipulation for Entry of Order Regarding the Production of Electronically Stored Information (“ESI”) and Hard Copy Documents to assist with discovery and production of documents. After careful consideration, it is hereby ORDERED as follows:
I. PURPOSE AND LIMITATIONS.
This Order regarding the production of Electronically Stored Information (“ESI”) and Hard Copy Documents (collectively, “Document” or “Documents”) shall govern discovery of Documents in this case as a supplement to the Federal Rules of Civil Procedure. This Order is intended to provide for effective and efficient discovery in accordance with the Federal Rules of Civil Procedure. Nothing in this Order alters any party's rights, obligations, and responsibilities under the Federal Rules of Civil Procedure. Nothing contained herein is intended to or shall serve to limit a party's right to conduct a review of Documents, ESI, or information (including metadata) for relevance, responsiveness, and/or segregation of privileged and/or protected information before production.
II. COOPERATION AND PROPORTIONALITY.
The parties are aware of the importance the Court places on cooperation and commit to cooperate in good faith throughout the matter, including with discovery and production of documents. The parties agree to take the proportionality considerations addressed in the Federal Rules of Civil Procedure into account for purposes of preservation and production of Documents in this action. This Order is not intended to expand the parties' obligations under the Federal Rules of Civil Procedure.
III. PRODUCTION FORMATS.
The parties agree to produce documents in the formats set forth in Appendix 1 and 2 attached hereto.
IV. MODIFICATION.
This Order may be modified by a written stipulation of the parties or by the Court for good cause shown.
V. MISCELLANEOUS PROVISIONS.
1. Technical Variances. Recognizing that each producing party may experience production issues due to data systems or files that may not be fully compatible with the technical specifications set forth herein, any practice or procedure set forth herein may be varied by agreement of the parties, confirmed in writing, to accommodate such issues or where such variance is deemed appropriate to facilitate the timely and economical production of Documents or ESI. No. party shall unreasonably object to any such variance.
2. Reproduction as Natives. The parties agree that to the extent any party seeks production in native format of specifically identified ESI produced originally in TIFF form, the producing party shall respond reasonably and in good faith to any such request.
The Court, having reviewed the information contained in the Stipulation and Order completed and filed jointly by the parties to this action, hereby ADOPTS the parties' plan.
SO ORDERED.
APPENDIX 1 PRODUCTION DELIVERY REQUIREMENTS
I. GENERAL PRODUCTION PROVISIONS
A. The parties have agreed that ESI should be produced as TIFF images and in Native format where applicable with accompanying data and image load files as set forth in detail below.
B. TIFF Image Files: The parties agree that all Documents, with the exception of Documents produced in Native format, will be produced as single-page black and white Group IV TIFF image files of at least 300 dpi resolution with 1 bit depth. Page 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. Each image file will use the Bates number of the page as its unique file name. Original document orientation as displayed in the native file should be maintained in the TIFF image (i.e., portrait to portrait and landscape to landscape).
C. Text Files: Each Document produced under this Order shall be accompanied by a document level text file containing all of the text for that document, not one text file per page. Each text file shall be named to use the Bates number of the first page of the corresponding document. The text files shall be generated by extracted text from native files and OCR text files from hard copy scanned documents as applicable. The .DAT load file shall include a link to the corresponding text file.
D. OCR Text Files: The parties will provide searchable OCR text of any paper or imaged Documents, unless the parties agree or the Court determines that the utility of the OCR is outweighed by the expense. In that case, the producing party will produce the documents as they are kept in the ordinary course of business.
E. Extracted Text Files from ESI: The parties shall extract the text of each ESI item directly from the ESI native file, where extracted text is reasonably available. For contacts and calendars collected and/or processed after the execution date of this Order, fields should be extracted and produced as text.
F. OCR Text for Redacted Documents: The parties will provide searchable OCR text for any redacted files.
G. Bates Numbering:
a. Each TIFF image produced under this Order should be assigned a Bates number that must: (1) be unique across the entire document production; (2) maintain a constant length of nine numeric digits (including 0-padding) across the entire production; (3) contain only alphanumeric characters, no special characters or embedded spaces; and (4) be sequential within a given Document. The producing party will identify the Bates number range of each production in a cover letter or production log accompanying the production. If a producing party skips a Bates number or set of Bates numbers in a production, the producing party will identify and note the gap in the cover letter or production log accompanying the production.
b. The producing party will brand all TIFF images in the lower right-hand comer with its corresponding Bates number, using a consistent font type and size. If the receiving party believes that a Bates number obscures the content of a Document, then the receiving party may request that the Document be produced with the Bates number in a different position.
H. Re-Production of Prior or Other Litigation Documents. Where a requesting party seeks re-production of a set of documents produced in a prior litigation or any other proceeding, or where a prior production of documents or ESI by a party in a prior litigation or any other proceeding is the only reasonably accessible source of those documents or ESI to be produced by a party in this litigation, the producing party may re-produce such documents in the manner in which they were produced in the prior case, including all objective coding or metadata fields required by this protocol to the extent reasonably available to the producing party as part of the productions set. For any such re-production in accordance with this Paragraph, the producing party is not obligated to re-format the prior production in accordance with the production specifications in ESI stipulation, but must provide Bates numbering and confidentiality designations specific to this litigation.
I. Parent-Child Relationships: Parent-child relationships for all embedded ESI documents (e.g., the association between an attachment and its parent email, or a spreadsheet embedded within a word processing document), must be preserved by assigning sequential Bates numbers to all items within the parent-child group, and identifying those Bates numbers in the relevant ESI metadata and coding fields specified in Appendix 2. For example, if a party is producing an email with embedded attachments or hyperlinked documents, the attachments or hyperlinked documents must be processed and assigned Bates numbers in sequential order, following consecutively behind the parent email. Not all attachments may be produced - for example, privileged or nonresponsive attachments may be removed, but all documents within responsive families will be Bates numbered prior to production.
J. Color Documents: The producing party shall provide photographs, design drawings, PowerPoint files, or other Documents and/or ESI containing color that is necessary to decipher the meaning, context, or content of the Documents and/or ESI in color. Other Documents and/or ESI that display information in color that is deemed as irrelevant to the meaning of a document need not initially be produced in color but may do so after a reasonable request. The producing party will not unreasonably deny such a request by the requesting party to reproduce specific documents in color. The production of such Documents and/or ESI in color shall be made in single-page JPEG format, provided JPEG format offers sufficient quality for the review of these Documents and/or ESL If any party deems the quality of the document produced in JPEG format to be insufficient, the producing party may produce the color image in TIFF or PDF format.
K. Confidentiality Designations: If a particular Document has a confidentiality designation, the designation shall be stamped on the face of all TIFF images pertaining to such Document, in the lower left-hand comer of the Document, or as close thereto as possible while preserving the underlying image. If the receiving party believes that a confidentiality designation obscures the content of a Document, then the receiving party may request that the Document be produced with the confidentiality designation in a different position. No. party may attach to any filing or any correspondence addressed to the Court (including any Magistrate Judge), or any adverse or third party, or submit as an exhibit at a deposition or any other judicial proceeding, a copy (whether electronic or otherwise) of any native format Document produced by any party without ensuring that the corresponding Bates number and confidentiality legend, as designated by the producing party, appears on the Document. For each document that is marked confidential, a Confidentiality field will be populated with the word “Confidential” in the .dat file. Also, any documents marked “Confidential” must be handled in accordance with the Protective Order entered in this case.
II. PRODUCTION OF HARD COPY DOCUMENTS
A. All hard copy Documents that are scanned as described in Section IV will be produced in electronic form. Where necessary and practicable, hard copy Documents in color will be scanned in color to ensure full information is communicated in the scanned copy. Scanned color documents will be provided in JPG file format.
B. Unitization of Paper Documents: To the extent practicable, hard copy Documents shall be unitized using logical document determinations or “LDD.”
C. Identification: Where a Document or group of Documents has an identification spine, “post-it note, ” or any other label, the information on the label shall be scanned and produced to the extent practicable.
D. Custodian Identification: The parties will utilize reasonable best efforts to ensure that paper records for a particular custodian or department level custodian, which are included in a single production, are produced in consecutive Bates stamp order.
E. Metadata: The metadata associated with each hard copy Document need only identify the Bates number, the custodian associated with that hard copy Document, and any Confidential Designation or Redaction applied to that Document.
III. PRODUCTION OF “ESI”
A. De-NISTING and System Files: ESI productions shall 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. De-NISTED files need not be produced. The parties may mutually agree upon any additional file types that can be excluded from review and production. A producing party shall identify any additional standard, readable, and reviewable file types which have been excluded from its document review population for any production made following the date of this Order, and will utilize reasonable best efforts to do the same with respect to any productions made prior to the date of this Order.
If a party excludes from review a standard, readable, and reviewable file type not within the industry standard, that party must disclose such an exclusion to the other parties.
B. Native Files: Certain files types, such as presentation-application files (e.g., MS PowerPoint), spreadsheet-application files (e.g., MS Excel, .csv), and multimedia audio/visual files such as voice and video recordings (e.g., .wav, .mpeg, and .avi), shall be produced in native format. For files produced in native format, the producing party shall provide a single-page TIFF slipsheet with the applicable Bates stamp indicating that a native item was produced. The corresponding load (.DAT) file shall include a NativeFilelink which provides the relative path linking information for each native file that is produced. In addition, the confidentiality designation will be indicated in the name of the native file where reasonably feasible.
C. Metadata Fields and Processing:
a. ESI shall be processed in a manner that preserves the source native file and relevant metadata without modification, including their existing time, date, and time-zone metadata consistent with the requirements provided in this Order. The producing party will provide information on the time zone the data was processed in to the receiving party.
b. Hidden text: ESI shall be processed, to the extent practicable, in a manner that preserves hidden columns or rows, hidden text, notes, or worksheets, speaker notes, tracked changes, redlines and comments. Upon request, absent any objections under the Federal Rules of Civil Procedure, a producing party will produce files with any such information in native format.
c. Compressed Files and Encrypted Files: Compressed file types (i.e., .CAB, GZ, .TAR .Z, .ZIP) shall be decompressed in a reiterative manner to ensure that a zip within a zip is decompressed into the lowest possible compression resulting in individual files. The producing party will take reasonable steps, prior to production, to unencrypt any discoverable electronically stored information that exists in encrypted format (e.g., because password- protected) and that can be reasonably unencrypted.
d. Microsoft “Auto” Feature and Macros: For Microsoft Excel (.xls), Microsoft Word (.doc), and Microsoft PowerPoint (.ppt) documents that contain “auto” features, (e.g., where documents have an automatically updated date and time in the document), the metadata associated with such files shall accurately reflect the automatically populated fields (i.e., the metadata date or other automatically populated field will reflect the date and/or entry for how the document was used or held in the ordinary course of business).
e. Metadata and Coded Fields: ESI items shall be produced with all of the metadata and coding fields set forth in Appendix 2.
D. This Order does not create any obligation to create or manually code fields that are not automatically generated by the processing of the ESI, or that do not exist as part of the original metadata of the Document; provided, however, that the producing party must populate, where possible, the (a) BegBates, (b) EndBates, (c) BegAttach, (d) EndAttach, (e) Custodian, (f) NativeFileLink fields, if applicable, (g) TextPath, (h) Redaction status, and (i) Confidentiality designation. These fields should be populated for all produced ESI, except hard copy Documents converted to electronic form (which are addressed above in Section 11), regardless of whether the fields can be populated pursuant to an automated process.
IV. DATABASES, STRUCTURED, AGGREGATED OR APPLICATION DATA
A. The Parties will produce documents collected from databases or other structured databases in a reasonably useable format. If the data cannot be produced in a reasonably useable format, the parties will meet and confer to address the production format. Prior to or during any such meet and confer, the producing party will provide sufficient information to enable the receiving party to evaluate the best method and format of production If the parties cannot reach agreement, the matter will be decided by the Court or its designee.
V. RESPONSIVENESS, PRIVILEGE AND REDACTIONS
A. The parties agree that all non-privileged attachments to an e-mail that is responsive to a discovery request must be Bates numbered and produced. Non-privileged cover e-mails to responsive documents will be deemed responsive and produced.
B. To the extent that a party reasonably determines that e-mail or related attachments that are responsive to a document request are not discoverable because they are subject to a Privilege, the responding party shall produce a log addressing each e-mail and attachment.
C. Redactions:
The parties agree that where ESI items need to be redacted, they shall be produced in TIFF format with each redaction clearly indicated or where TIFF format is not practicable, in redacted native format, as noted below. Any unaffected data fields shall be provided. The redaction of any material for privilege or other reason shall be governed by the applicable rules and case law regarding privilege and the provisions contained in the Protective Order entered in this action. Documents that are to be produced in native format, but that require redactions may be produced as TIFF images with the relevant portions redacted, or if a TIFF image production is not practicable (e.g., the file is a video or very large spreadsheet), the producing party may produce a copy of the native file with the relevant portions replaced with “REDACTED” or a similar mark. If modification of a native file is required for redaction purposes, metadata information associated with that file should remain unchanged, unless it also requires redaction. For each document that is redacted, a Redaction field will be populated with the word “REDACTED” in the .DAT file. Also, the producing party will keep a pristine original copy of the native document.
D. Printing Specifications for Excel and PowerPoint files:
For Excel and PowerPoint type files that are printed to TIFF for redaction and redacted, the following printing options shall be enabled:
Excel Print to TIFF Options
• Unhide columns and rows
• Unhide worksheets
• Autofit columns and rows, settings to be over by columns first and, then down by rows
• Wrap text
• Print gridlines
• Do not apply Autofilter
• Display headings
• Display comments
• Header and Footer filename field handling: Show field code
PowerPoint Print to TIFF Options
• Print notes pages
• Print hidden slides
• Print comments
a. The producing party shall also make reasonable efforts to ensure that any spreadsheets produced only as TIFF images because of redactions are formatted so as to be legible. For redacted items which were originally ESI, all metadata fields noted in this protocol that do not contain privileged or protected information will be provided and will include all non-redacted data. A document's status as redacted does not relieve the producing party from providing all of the metadata required herein.
E. De-duplication and Document Families:
a. ESI may be de-duplicated globally at the parent level using MD5 hash or SHA-1 hash. For emails, de-duplication may be performed using a hash calculated using combination of metadata fields. Such hash shall, at a minimum, account for all sender and recipient metadata including BCC recipients, the email subject, date sent, and attachment names.
The parties are permitted to produce the longest unique email chain and do not need to separately produce the lesser-included emails unless those lesser-included emails have bcc recipients or unique attachments not included in the longest chain. If a lesser-included email has a bee recipient or unique attachment, then the lesser-included email must be separately produced with the attachments
If a party produces only inclusive email, the parties agree to redact any privileged content or message component and produce in full the rest of the conversation in the inclusives.
“Near duplicate” documents shall be produced rather than removed. The producing party need only produce a single copy of a particular ESL
The hash value for each item shall be reflected in the .DAT load file in the HashValue field specified in Appendix 2. If a producing party elects to de-duplicate globally, the producing party shall identify custodians who were in possession of a de-duplicated Document in the AllCustodian metadata field specified in Appendix 2. This means that the field “AllCustodian” will be populated showing all custodians who had a copy of the same document which is not being produced because of de-duplication.
b. De-duplication shall not break apart families and shall be performed at a family level. 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 members of that group must be also be produced or else logged and no such member shall be withheld from production as a duplicate.
F. Load Files:
The data load file should be in standard Concordance format (.DAT). The .DAT file shall contain a relative path to the corresponding Native file. Concordance Data Load Files: The data load file should use standard Concordance delimiters:
• Comma - f (ASCII 20);
• Quote - þ (ASCII 254);
• Newline - ® (ASCII l74).
• The first line of the .DAT file should contain the field names arranged in the same order as the data is arranged in subsequent lines.
• All date fields should be produced in mm/dd/yyyy format, if possible. Date fields may be combined date/time fields
• All produced attachments should sequentially follow the parent Document/email.
Sample Concordance .DAT Load File:
þBegBatesþ¶þBegattatchþ¶Custodianþ¶þNative Path¶þþExtracted Textþ þABC000001þ¶þABC000001þ¶þSampleþ¶þVOL001\NATIVES\001\ABC000001.xlsþ¶þTEXT \001\ABC000001.t
tþþABC000002þ¶þABC000001þ¶þSampleþ¶þNATIVES\001\ABC000002.gifþ¶þJTEXT \001\ABC000002.txtþ
The image load file must be in standard Option (.OPT) format and must reference each TIFF file in the corresponding production, and the total number of TIFF files referenced in the load file must match the total number of image files in the production. The total number of Documents referenced in a production's data load file should match the total number of designated Document breaks in the corresponding image load file for that production. In any deliverable volume, documents should be organized in such a way that each folder in the volume contains 1000 files (each TIFF page or native file is a single file) as one file per folder.
• Every image in the delivery volume should be cross-referenced in the image load file.
• The imageID key should be named the same as the Bates number of the page.
• Load files should not span across media (e.g., CDs, DVDs, hard drives, etc.), i.e., a separate volume should be created for each piece of media delivered.
Sample Concordance/Opticon Image (.OPT) Load File:
MSC00000l, MSC00l, \VOL00l\IMAGES\001\MSC00000l.TIF, Y,,, 2
MSC000002, MSC001, \VOLOO1\IMAGES\001\MSC000002.TIF,, ,,
MSC000004, MSC001, \VOL00l \IMAGES\001\MSC000004.TIF, Y,,, 2
MSC000005, MSC001, \VOL00l \IMAGES\001\MSC000005.TIF,, ,,
OCR/Extracted Text Files:
• OCR or Extracted Text files shall be provided in a separate directory containing Document level text files. The .DAT file shall contain a relative path to the corresponding text file. OCR or Extracted text itself should not be included in the .DAT file:PROD001\TEXT\001\ABC00015.txt
APPENDIX 2: ESI METADATA AND CODING FIELDS
The chart below describes the metadata fields to be produced, where reasonably available, in generic, commonly used terms which the producing party is to adapt to the specific types of ESI it is producing, to the extent such metadata fields exist associated with the original electronic Documents and are automatically generated as part of the electronic data discovery process. Any ambiguity about a metadata field should be discussed with the receiving party prior to processing the subject ESI for production.
| Field Name | Field Description |
| BegBates | First Bates number (production number) of an item |
| EndBates | Last Bates number (production number) of an item **The EndBates field should be populated for single-page items. |
| AttachName | File name of the attachment, with any attachments separated by semi-colon. |
| BegAttach/Group ID | First Bates number of family group. |
| EndAttach | Last Bates number of attachment range (i.e., Bates number of the last page of the last attachment) |
| PgCount | Number of pages in the item |
| Custodian | Name of person or source from whose/which files the item is produced |
| AllCustodian | Name of the person(s), in addition to the Custodian, from whose files the item would have been produced if it had not been de-duplicated |
| FileSize | Size (in kilobytes) of the source native file |
| The directory structure or path where the original file was stored on the party's source computer system, ending in the filename. Any container name (such as ZIP or PST containers) is included in the path. |
| Field Name | Field Description |
| HashValue | The MD5 or SHA-1 or IntMsgID hash value of the item. |
| NativeFileLink | Relative path for documents provided in native format only. **The linked file must be named per the BegBates value. |
| SourceParty | Name of entity or party producing the item |
| RecordType | Indicates item type (e.g., email, edoc, attachment) |
| FileType | (e.g., Outlook, Adobe Acrobat, MS Word, etc.) |
| FileExtension | Indicates file extension of the file (e.g., .docx, .pptx) |
| DateSent (mm/dd/yyyy) | Date email or calendar item was sent |
| TimeSent (hh:mmAM/PM) | Time email or calendar item was sent (Date and time fields may be combined) |
| DateReceived | Date email or calendar item was received |
| TimeReceived | Time email or calendar item was received (Date and time fields may be combined) |
| To | The names and/or SMTP email addresses of all recipients that were included on the “To” line of the email or calendar item |
| From | The name and/or SMTP email address of the sender of the email or calendar item |
| cc | The names and/or SMTP email addresses of all recipients that were included on the “CC” line of the email or calendar item |
| BCC | The names and/or SMTP email addresses of all recipients that were included on the “BCC” line of the email or calendar item |
| Number of Attachments | Number of attached, embedded or grouped items |
| DateCreated (mm/dd/yyyy) | Date the item was created |
| TimeCreated (hh:mm AM/PM) | Time the item was created (Date and time fields may be combined) |
| ModifiedBy | Person who last modified or saved the item, as populated in the metadata or document properties of the native file |
| LastModDate (mm/dd/yyyy) | Date the item was last modified |
| LastModTime (hh:mm AM/PM) | Time the item was last modified |
| FileName | The filename of the source native file for an ESI item |
| Title | Any value populated in the Title field of the source file metadata or item properties |
| Subject/E-Mail Subject | Any value populated in the Subject field of the source file metadata or document properties (e.g., subject line of email or calendar item) |
| Author | Creator of the document; any value populated in the Author field of the source file metadata or document properties |
| TextPath | Full relative path to the location of the document-level text file. |
| Redacted | User-generated field that will indicate redactions. With the word “REDACTED”. Otherwise, blank. |
| Confidentiality | User-generated field that will indicate confidentiality. With the word “CONFIDENTIAL”. Otherwise, blank. |
This field may be excluded if the producing party determines it includes information protected by any applicable privilege, doctrine, or immunity.