Opinion
2:21-cv-01551-TSZ
07-07-2023
JEREMY JAEGER, on behalf of himself and all others similarly situated, Plaintiff, v. ZILLOW GROUP, INC., et al., Defendants.
Steve W. Berman (WSBA No. 12536) Catherine Y. N. Gannon Catherine Y. N. Gannon (WSBA No. 47664) HAGENS BERMAN SOBOL SHAPIRO LLP Reed R. Kathrein (pro hac vice) Lucas E. Gilmore (pro hac vice) HAGENS BERMAN SOBOL SHAPIRO LLP Lead Counsel for Lead Plaintiff Jaeger Stacey M. Kaplan (pro hac vice) KESSLER TOPAZ MELTZER & CHECK, LLP One Sansome Street, Gregory M. Castaldo (pro hac vice) Evan R. Hoey (pro hac vice) Helen J. Bass (pro hac vice) Additional Counsel for Lead Plaintiff Jaeger Sean C. Knowles, WSBA No. 39893 PERKINS COIE LLP Peter B. Morrison (pro hac vice) Virginia F. Milstead (pro hac vice) Winston Hsiao (pro hac vice) Raza Rasheed (pro hac vice) SKADDEN, ARPS, SLATE, MEAGHER & FLOM, LLP Attorneys for Defendants Zillow Group, Inc., Richard Barton, Allen Parker, and Jeremy Wacksman
Steve W. Berman (WSBA No. 12536) Catherine Y. N. Gannon Catherine Y. N. Gannon (WSBA No. 47664) HAGENS BERMAN SOBOL SHAPIRO LLP Reed R. Kathrein (pro hac vice) Lucas E. Gilmore (pro hac vice) HAGENS BERMAN SOBOL SHAPIRO LLP Lead Counsel for Lead Plaintiff Jaeger
Stacey M. Kaplan (pro hac vice) KESSLER TOPAZ MELTZER & CHECK, LLP One Sansome Street, Gregory M. Castaldo (pro hac vice) Evan R. Hoey (pro hac vice) Helen J. Bass (pro hac vice) Additional Counsel for Lead Plaintiff Jaeger Sean C. Knowles, WSBA No. 39893 PERKINS COIE LLP
Peter B. Morrison (pro hac vice) Virginia F. Milstead (pro hac vice) Winston Hsiao (pro hac vice) Raza Rasheed (pro hac vice) SKADDEN, ARPS, SLATE, MEAGHER & FLOM, LLP Attorneys for Defendants Zillow Group, Inc., Richard Barton, Allen Parker, and Jeremy Wacksman
AGREEMENT REGARDING DISCOVERY OF ELECTRONICALLY STORED INFORMATION AND ORDER
Thomas S. Zilly United States District Judge
The parties hereby stipulate to the following provisions regarding the discovery of electronically stored information (“ESI”) in this matter as a supplement to the Federal Rules of Civil Procedure, this Court's Local Rules and any other applicable orders and rules:
A. General Principles and Statement of Cooperation
1. An attorney's zealous representation of a client is not compromised by conducting discovery in a cooperative manner. The failure of counsel or the parties to litigation to cooperate in facilitating and reasonably limiting discovery requests and responses raises litigation costs and contributes to the risk of sanctions. The parties are aware of the importance the Court places on cooperation and commit to cooperate in good faith regarding the production of documents and ESI and any disputes or concerns regarding such productions.
2. As provided in LCR 26(f), the proportionality standard set forth in Fed. R. Civ. P.
26(b)(1) must be applied in each case when formulating a discovery plan. To further the application of the proportionality standard in discovery, requests for production of ESI and related responses should be reasonably targeted, clear, and as specific as possible. This agreement is intended to assist the parties in identifying relevant responsive information that has been stored electronically and is proportional to the needs of the case. The agreement does not supplant the parties' obligations to comply with Fed.R.Civ.P. 34.
B. Liaison
1. The parties have identified liaisons to each other who are and will be knowledgeable about and responsible for discussing their respective documents and ESI. Each liaison is, or has access to those who are, knowledgeable about the technical aspects of e-discovery, including the location, nature, accessibility, format, collection, search methodologies, and production of ESI in this matter.
2. The parties will rely on the liaisons, as needed, to confer about production issues and to help resolve disputes without Court intervention. Any party may change its designated liaison by providing written notice to the other parties.
C. ESI Disclosures
By July 28, 2023, or along with the party's responses and objections to initial discovery requests propounded by the requesting party, whichever occurs later, each party shall disclose:
1. Custodians, The custodians reasonably likely to have discoverable ESI in their possession, custody, or control. The custodians shall be identified by name, title, connection to the instant litigation, and the type and sources of the information under the custodian's control.
2. Non-Custodial Data Sources. A list of non-custodial data sources (e.g., shared drives, servers, databases, collaborative software applications), if any, likely to contain discoverable ESI.
3. Third-Party Data Sources. A list of third-party data sources within the party's custody, control, or possession, if any, likely to contain discoverable ESI (e.g., third-party email providers, mobile device providers, cloud storage) and, for each such source, the extent to which a party is (or is not) able to preserve information stored in the third-party data source.
4. Inaccessible Data. A list of data sources or custodians, if any, likely to contain discoverable ESI (by type, date, custodian, electronic system or other criteria sufficient to specifically identify the data source) that a party asserts is not reasonably accessible under Fed.R.Civ.P. 26(b)(2)(B).
D. ESI Discovery Procedures
1. On-Site Inspection of Electronic Media. Such an inspection shall not be required absent a demonstration by the requesting party of specific need and good cause or by agreement of the parties.
2. Search Methodology. The parties shall timely confer in good faith to attempt to reach agreement on appropriate search terms and queries, file type and date restrictions, data sources (including custodians, custodial data sources, and non-custodial data sources) that may be used to identify responsive documents and ESI, and other appropriate computer- or technology-aided methodologies, before any such effort is undertaken. The parties shall continue to cooperate in revising the appropriateness of the proposed search methodology and if an impasse is reached will promptly present any discovery dispute to the Court, but in all events no later than 120 days prior to the substantial completion deadline.
a. Prior to running searches:
i. The producing party shall initially disclose the data sources (including custodians, custodial data sources, and non-custodial data sources), search terms and queries, any file type and date restrictions, and any other methodology (including computer- or technology aided methodologies) that it proposes to use to locate ESI likely to contain responsive and discoverable information by July 28, 2023, or along with the party's responses and objections to initial document requests propounded by the requesting party, whichever occurs later.
ii. To the extent search terms are proposed, the producing party shall, provide a list of proposed search terms that it believes would lead to the identification of responsive documents and ESI. To the extent reasonably possible, search terms shall be crafted to include relevant terminology, synonyms, nicknames, code words, euphemisms, acronyms, slang, terms of art, and other language reasonably likely to be contained in responsive documents, and variations on search syntax (e.g., wild card characters, truncation, stem words, fuzzy logic, and proximity terms or connectors).
iii. The requesting party may also request additional search terms be utilized in the identification of responsive documents and ESI, and provide these additional search terms within one week of receipt of the producing party's search term proposals. The producing party agrees to consider in good faith the additional search terms requested by the requesting party. To the extent a producing party objects to requested search terms, it shall provide a reasonably detailed explanation of the basis for its objection within two weeks of receipt (i.e. the requested additional term(s) results in an excessive amount of unique document hit families to review disproportionate to the need or relevance of the term, and/or is likely to result in significant mishits for particular reason(s)), in writing, and the parties shall meet and confer regarding the proposed terms. A producing party objecting to requested search terms will also provide backup documentation, if available (e.g. a search term report showing hit counts, unique counts for each search query (including with families) on a de-deduplicated data set). The parties shall also discuss
whether any testing, sampling or quality control measures will be conducted to evaluate the sufficiency of the search terms. If disputes still exist at the end of the meet-and-confer process, the parties will submit them to the Court pursuant to the Court's practices and procedures for raising discovery disputes no later than 120 days before substantial completion.
iv. To ensure appropriate validation of the search terms, the producing party must provide unique hit counts for each search query and identify any Boolean search operators or syntax in the additional search terms requested by the requesting party that are not compatible with the producing party's platform.
v. After disclosure, the parties will engage in a meet and confer process to resolve any disputes regarding custodians, search terms, search methodology and/or data sources by August 25, 2023.
b. Upon reasonable request, a party shall disclose information relating to network design, the types of databases, database dictionaries, the access control list and security access logs and rights of individuals to access the system and specific files and applications, the ESI document retention policy, organizational chart for information systems personnel, or the backup and systems recovery routines, including, but not limited to, tape rotation and destruction/overwrite policy.
3. Format.
a. ESI will be produced to the requesting party as outlined in Appendix A.
4. De-duplication. The parties shall de-duplicate their ESI production as outlined in Appendix A. However, a Producing Party must still ensure that all deduplicated custodians are identified in the All Custodians field, and the location of duplicate file paths are provided in the All Paths metadata field.
5. Metadata Fields. If the requesting party seeks metadata, the parties agree that
Appendix A will govern the production of metadata. The list of metadata type is intended to be flexible and may be changed by agreement of the parties, particularly in light of advances and changes in technology, vendor, and business practices,
6. Hard Copy Documents. If the parties elect to produce hard-copy documents in an electronic format, the production of hard-copy documents will be governed by Appendix A.
E. Phasing
1. When a party propounds discovery requests pursuant to Federal Rule of Civil Procedure 34, the parties agree to make best efforts to phase ESI production where reasonably necessary, and that they will meet and confer to discuss whether certain categories of information can be prioritized over other categories. Following the initial production, the parties will continue to prioritize the order of parties' document productions.
F. Preservation of ESI
The parties acknowledge that they have a common law obligation, as expressed in Fed. R Civ. P. 37(e), to take reasonable and proportional steps to preserve discoverable information in the party's possession, custody, or control. With respect to preservation of ESI, the parties agree as follows:
1. Absent a showing of good cause by the requesting party, the parties shall not be required to modify the procedures used by them in the ordinary course of business to back-up and archive data; provided, however, that the parties shall preserve all discoverable ESI in their possession, custody, or control.
2. The parties will supplement their disclosures in accordance with Fed. R. Civ. P 26(e) with discoverable ESI responsive to a particular discovery request or mandatory disclosure where that data is created after disclosure or response is made (unless excluded under Sections F(3) or G(1)-(2)).
3. Absent a showing of good cause by the requesting party, the following categories of ESI need not be preserved:
a. Deleted, slack, fragmented, or other data only accessible by forensics.
b. Random access memory (RAM), temporary files, or other ephemeral data that are difficult to preserve without disabling the operating system.
c. On-line access data such as temporary internet files, history, cache, cookies, and the like.
d. Data in metadata fields that are frequently updated automatically, such as last-opened dates.
e. Back-up data that are duplicative of data that are more accessible elsewhere.
f. Server, system or network logs.
g. Data remaining from systems no longer in use that is unintelligible on the systems in use.
h. Electronic data (e.g., email, calendars, contact data, and notes) sent to or from mobile devices (e.g., iPhone, iPad, Android devices), provided that a copy of all such electronic data is automatically saved in real time elsewhere (such as on a server, laptop, desktop computer, or “cloud” storage) the producing party has possession, custody or control over those other storage locations and they are being searched.
3. The parties agree to disclose categories and sources of relevant ESI they reasonably believe has not been preserved, or should not be preserved on grounds of: undue burden and cost, a party's retention policy, or other proportionality factors.
G. Privilege
1. A producing party shall create a privilege log of all documents fully withheld from production on the basis of a privilege or protection, unless otherwise agreed by the parties or excepted by this Agreement and Order. Each privilege log shall contain the following information in tabular form: (1) a unique identification number for each document; (2) date of the document; (3)author information; (4) all recipient information; basis for the privilege claim (attorney client privileged or work product protection); and a description of the document that explains what is being withheld and why.
2. For ESI, the privilege log shall be initially generated using available metadata, including author/recipient or to/from/cc/bcc names; the subject matter or title; and date created. Should the available metadata provide insufficient information for the purpose of evaluating the privilege claim asserted, the producing party shall include such additional information as required by the Federal Rules of Civil Procedure. Privilege logs will be produced according to the agreements of the parties outlined in the joint 26(f) report.
3. Redactions need not be logged so long as (1) the basis for the redaction is clear on the redacted document; (2) the producing party makes its assertions using redaction stamps; (3) the “Redacted” metadata filed is populated indicating the presence of redactions. All other redactions must be logged.
4. With respect to privileged or work-product information generated after the filing of the complaint, parties are not required to include any such information in privilege logs.
5. Activities undertaken in compliance with the duty to preserve information are protected from disclosure and discovery under Fed.R.Civ.P. 26(b)(3)(A) and (B).
6. Pursuant to Fed.R.Evid. 502(d), the production of any documents, in this proceeding shall not, for the purposes of this proceeding or any other federal or state proceeding, constitute a waiver by the producing party of any privilege applicable to those documents, including the attorney-client privilege, attorney work-product protection, or any other privilege or protection recognized by law. Information produced in discovery that is protected as privileged or work product shall be immediately returned to the producing party, and its production shall not constitute a waiver of such protection.
7. Nothing herein restricts the right of a party to challenge a party's claim of privilege.
a. If a producing party believes that privileged material was inadvertently produced, the producing party must notify the party (in writing or orally on the record during a deposition) that received the information of the privilege claim and the basis for it (“Recall Notice”). Within 5 days of the Recall Notice, the producing party shall produce a privilege log with respect to the privileged material.
b. Upon receipt of a Recall Notice, the receiving party must sequester and cease use of the claimed privileged material until any dispute regarding the claim of privilege is resolved. Further, within 10 days after receipt of the producing party's production log, the receiving party (i) must return or destroy the claimed privileged material and any copies it has and (ii) may notify the disclosing party in writing whether it objects to the designation of the material as privileged or protected.
c. In the event the receiving party asserts an objection to the Recall Notice, the Parties will promptly meet and confer. If an impasse is announced, then either Party may seek Court resolution by initiating the informal and expedited joint motion procedures set forth in Local Rule 37(a)(2).
H. Modification
1. This Order may be modified by stipulation of the parties or by the Court for good cause shown.
ORDER
Based on the foregoing, IT IS SO ORDERED.
APPENDIX A
I. FORMAT OF PRODUCTION
A. All documents shall be produced in the following formats when reasonably feasible:
1. Electronic Production of Paper Documents. Documents that are maintained in paper format shall be scanned as document level PDF files, and shall reflect the full and complete information contained in the original Document.
a. Hard copy Documents shall be produced with associated OCR files at the same time that the PDF image files are produced and with a Load File that includes at least the following Metadata fields: Begin Bates; End Bates; Begin Family; End Family; Pages; TextPath; Placeholder; File Extension; Custodian; All Custodians; Confidentiality; and Redacted, as those fields are described in Section II.A, below.
b. When subjecting physical documents to an OCR process, the settings of the OCR software shall maximize text quality over process speed. Any settings such as “auto-skewing” or “auto-rotation,” should be turned on when documents are run through the process. Paper Documents that contain fixed notes shall be scanned with the notes affixed, if it can be done so in a manner so as not to obstruct other content on the document. If the content of the Document is obscured by the affixed notes, the Document and notes shall be scanned separately.
2. Production of Electronically Stored Information (ESI). Unless otherwise specified, Document images shall be generated from electronic Documents in a set of single page, Group IV TIFF/JPEG files with an image resolution that shall be at least 300 DPI and 81/2 X 11-inch page size, except for documents requiring different resolution, color or page size, with a file naming convention that shall match the Bates number that reflect the full and complete information contained on the original Document. In the event a Document is redacted, the Producing Party shall withhold the redacted portion of text for that Document.
a. Electronic messages. Electronic messages shall be produced in a format that preserves the presentational features of the original message, such as emojis, images, video files, animations, and the like. The parties will meet and confer regarding the production format for electronic messages from ephemeral messaging systems, mobile device applications, and cloud sources.
b. Collaborative Tools and Platforms. The parties shall meet and confer regarding the production format for Documents, chat messages, and ESI other than electronic messages, contained within or stored on collaboration tools and platforms.
c. Structured Data. To the extent a response to discovery requires production of electronic information stored in a database, the parties will meet and confer regarding appropriate methods of production from such databases, including whether all relevant information may be provided by querying the database for discoverable information and generating a report in a reasonably usable and exportable electronic file, as well as the appropriate content and format of any report to be generated from querying such databases and any additional information necessary to understand the data contained in the databases or database exports. In meeting and conferring, the producing party shall make all disclosures necessary to ensure a meaningful meet and confer regarding the content and format of any ESI to be produced from such databases.
d. Attachments. If any part of an email or its attachments is responsive, the entire email and all attachments shall be produced, except: (i) where an attachment is withheld pursuant to a valid claim of privilege, in which case that attachment will be replaced with a single-page PDF placeholder image stating “DOCUMENT WITHHELD/PRIVILEGED”; and (ii) where the attachment is a non-substantive, automatically generated embedded file (e.g., logos) or formatting file (e.g., .ole or .dll). Attachments shall be produced sequentially after the parent email.
e. Linked Documents. Documents sent via links within emails (e.g., Google Workspace, Microsoft O365, Slack etc.) shall be extracted from the links, and produced consistent with the manner for producing attachments described herein, and to the extent feasible, provided that linked documents are under the possession, custody or control of the producing party. To the extent that a party asserts that the production of such links is not feasible or that the linked documents are not within their possession, custody, or control, the parties shall meet and confer. Further, for such attachments, the Begin Family and End Family metadata fields shall be populated to show the family relationship.
f. Embedded Objects. Embedded files shall be produced as attachments to the document that contained the embedded file in the manner described herein, with the parent/child relationship preserved. The parties agree logos need not be extracted as separate documents as long as they are displayed in the parent document.
g. Redactions. The parties shall populate a “Redacted” metadata field for all documents containing redactions for information withheld pursuant to a valid claim of privilege.
3. File Structure. The Producing Party shall produce the following sets of files with each production.
a. Image Load File.
(1) Every document referenced in a production image load file must have all corresponding images, text and metadata.
(2) The name of the image load file must mirror the name of the delivery volume and should have an .OPT file extension.
(3) The volume names must be reasonably consecutive (e.g. ABC001, ABC002...).
(4) The load file must contain one line per image.
(5) Every image in the delivery volume must be contained in the image load file.
(6) The image key must be named the same as the Bates number of the image.
(7) Load files must not span across media.
(8) File should be placed in the root directory or a directory labeled “DATA.”
b. Metadata Load File.
(9) Each production has one load file, in “Concordance” style .DAT format.
(10) Values must be enclosed by þ (ASCII Decimal 254).
(11) Values must be separated by the “Device Control 4” character, ASCII decimal 20.
(12) First line must contain the column/field names (set forth in Section IV, below).
(13) The fields Begin Bates and End Bates must be present, and the first fields listed in the load file.
(14) The field NativePath must be present if native files are included in the document production.
(15) Each subsequent row must contain the Metadata for one Document.
(16) Every row must have the same number of columns/fields (empty values are acceptable).
(17) Text must be encoded in UTF-8.
(18) File should be placed in the root directory or a directory labeled “DATA.”
b. OCR and Extracted Text Files (.TXT Files).
(1) A single text file for each Document containing all the Document's pages, in text.
(2) Pages separated by form feed character (decimal 12, hex 0xC).
(3) Filenames should be of the form: <Bates num>.txt, where <Bates num> is the Bates number of the first page of the Document.
(4) Text must be encoded in UTF-8.
(5) Files should be placed in a directory labeled “TEXT.”
c. Image Files.
(1) Document images shall be single page, Group IV TIFF/JPEG files with an image resolution that shall be at least 300 DPI and 8 ½ X 11-inch page size, except for documents requiring different resolution, color or page size, with a file naming convention that shall match the Bates number.
(2) Filenames should be of the form: <Bates num>.<ext>, where <Bates num> is the BATES number of the first page of the document (i.e., the “Begin Bates” number), and <ext> is the appropriate extension for the image format (.pdf).
(3) Files should be placed in the “IMAGES” subdirectory.
4. Illegible Documents. Documents that cannot be read because of imaging or formatting problems, or because they are password-protected, shall be promptly identified by the Receiving Party. The Producing Party and the Receiving Party shall meet and confer to attempt to resolve problem(s).
5. Native Format Documents. The parties recognize that it may be appropriate for certain Documents to be produced in Native Format, such as spreadsheets, engineering drawings, presentations or slides, documents with tracked changes, audio and video files, and images. The production should preserve any use in Native Format Document of color and include all edits/comments, as well as the authors and date/time of the edits. In all cases, unless there is no textual content, an OCR or Extracted Text file shall be produced along with the Native File. The Receiving Party may request that the Producing Party produce additional file types of electronic Documents in Native Format where the converted image format distorts or causes the information to be improperly displayed.
a. Spreadsheets and Databases. To the extent that responsive documents exist in Excel, Access or other software program, such documents shall be
produced in Native Format unless the document needs to be redacted. An image placeholder shall be provided for each document produced in Native Format. Each placeholder shall contain the phrase “DOCUMENT PRODUCED IN NATIVE FORMAT,” or something similar, and shall contain the Bates number corresponding to the native file.
b. PowerPoint Presentations (PPT). PPT presentations should be produced in Native Format (e.g., as .PPT files). An image placeholder shall be provided for each document produced in Native Format. Each placeholder shall contain the phrase “DOCUMENT PRODUCED IN NATIVE FORMAT,” or something similar, and shall contain the Bates number corresponding to the native file.
c. Audio and Video Data. Parties should make best efforts to ensure care is taken for collection and production of any responsive audio and/or video data, and to preserve any Metadata that may be associated with those items. These data types may be stored in audio or video recordings, voicemail text messaging, and related/similar technologies.
d. Word Documents (or similar). Microsoft Word documents (.DOC,.DOCX, or substantially similar non-Microsoft file formats) that contain tracked changes and comments shall be produced in Native Format. An image placeholder shall be provided for each document produced in Native Format. Each placeholder shall contain the phrase “DOCUMENT PRODUCED IN NATIVE FORMAT,” or something similar, and shall contain the Bates number corresponding to the native file.
e. To the extent the Producing Party produces a Document in Native Format, the following specifications apply:
(1) Filenames must be unique in the production, unless the content is identical. Files should be named for the starting Bates number of the associated Document.
(2) The filename must retain the file extension corresponding to the original Native Format (e.g., an Excel 2003 spreadsheet's extension must be .xls).
6. Redactions. If documents that the parties have agreed to produce in native format need to be redacted pursuant to a valid claim of privilege, they shall, to the extent reasonably feasible, apply such redactions using a native redaction tool.
7. Color. For any non-native documents, production will be in color where color is material to the understanding of the document or parts thereof (e.g., pie and bar charts, images or pictures pasted within emails).
8. Production Media. A Producing Party may produce Documents electronically (via secure FTP, for example), or such other readily accessible computer or electronic media as the Producing Party and the Receiving Party may hereafter agree upon (the “Production Media”). When produced, the Production Media include correspondence indicating the production date, the production volume, the Bates range contained on the Production Media, and any confidentiality notation that may be required by the Protective Order entered in this case. If the Producing Party encrypts or “locks” the production, the Producing Party shall include, under separate cover, instructions regarding how to decrypt the files, and any necessary passwords.
9. Document Unitization. When scanning paper documents into Document images as described in Section I(1)(b)., they shall be unitized in a manner so as to maintain the Document(s) and any attachments as they existed in their original state, as reasonably feasible. Any applicable folder structure information should also be provided. Responsive attachments to e-mails stored shall be produced contemporaneously and sequentially immediately after the parent e-mail.
10. Duplicates. A Producing Party who has more than one identical copy of an electronic Document (identified by MD5 or SHA-1 hash values at the parentdocument level) shall only produce a single copy of that Document, in a manner that does not break up document families. Attachments may not be eliminated as duplicates for purposes of production, unless the parent email and all attachments are also duplicates. The parties agree that the following shall not be treated as duplicates, and may not be removed from the review set for purposes of producing documents and ESI in response to a discovery request: (i) emails that includes content in the BCC or other blind copy field and emails that do not include content in those fields, even if all remaining content in the email is identical; and (ii) near-duplicate documents are also not duplicates; and (iii) lesser included emails of a more inclusive email thread. De-duplication shall be done across the entire collection (global de-duplication) and the All Custodians field shall identify each custodian, separated by a semicolon, who was a source of that document, and the All Paths field shall identify each file path, separated by a semicolon, that was a source of that document. In the event of a rolling production, the producing party shall provide an overlay load file with updated All Custodian and All Paths metadata fields for all prior productions and shall identify whether the overlay is a full refresh of these fields, or a supplement of those fields.
11. Bates Numbering. Each Producing Party shall Bates number its production(s) as follows:
a. Each Bates number should consist of a unique identifier consisting of a prefix, followed by six numbers (e.g., ABC000001). The prefix should be substantially similar for all pages produced by the same Producing Party throughout this litigation. Each page of a Document must have its own Bates number, and Bates numbers should be sequential. Bates numbers shall not contain spaces.
b. Document Images. Each page of a produced Document shall have a legible, unique page identifier (Bates number) electronically “burned” onto the image at a location that does not unreasonably obliterate, conceal, or interfere with any information from the source Document. No other legend or stamp should be placed on the document other than a confidentiality designation (where applicable), a privilege designation, or a redactions (where applicable). For confidential documents the confidentiality designation shall be “burned” onto each Document's image at a location that does not unreasonably obliterate or obscure any information from the source Document.
c. Native Format Documents. In order to preserve the integrity of any Native Format Documents that will be produced, no Bates number, confidentiality legend or redaction information should be added to the content of the Native Format Document. Each native should have an individual Bates number assigned as the filename which may also contain the confidentiality designation of the file following the Bates number, (e.g., ABC000001-Confidential.xlsx)..
If documents cannot be rendered to a readable PDF format, and the document needs to be redacted for personally identifiable information or privileged content, the native documents may be redacted by creating a new copy of the native document and inserting “Redacted” or similar language where the protected content is located. In that circumstance, a pristine copy of the original native file will be retained and the party will identify documents redacted in native format in the production cover letter and in the Redacted metadata field.
II. METADATA FIELDS
A. For scanned hard copy documents, the Producing Party will provide the Metadata fields below.
| FIELD NAME | FIELD DESCRIPTION |
| Begin Bates | The production Bates number associated with the first page of a Document. |
| End Bates | The production Bates number associated with the last page of a Document. |
| BeginFamily | Begin Bates number of first page of the parent Document of family of attachments. |
| EndFamily | End Bates number of the last page of last attachment to a family of Documents. |
| Pages | Total number of pages in the Document. |
| TextPath | Link to text file for the document. |
| Placeholder | Identifies a Document has a placeholder image. |
| File Extension | The extension of the file. |
| FIELD NAME | FIELD DESCRIPTION |
| Custodian | Identification of the custodian(s) from whom the file was sourced. |
| All Custodians | Identification of all custodians of the document. |
| Confidentiality | Confidentiality designation. |
| Redacted | (Y/N) field that identifies whether the document is redacted. |
| Production Volume | Production volume number (e.g., VOL001, VOL002, etc.). |
| Producing Party | Name of party producing the Document. |
B. For ESI and documents that were originally stored in electronic format, all fields below should be provided, to the extent reasonably feasible. Unless otherwise agreed by the parties, the field-naming conventions shall be as stated below, and shall be consistently applied across all productions:
| FIELD NAME | FIELD DESCRIPTION |
| Begin Bates | The production Bates number associated with the first page of a Document. |
| End Bates | The production Bates number associated with the last page of a Document. |
| BeginFamily | Begin Bates number of the first page of parent Document of family of attachments. |
| EndFamily | End Bates number of the last page of last attachment to a family of Documents. |
| AttachCount | Number of document attachments. |
| AttachNames | Native file names of each individual attachment, separated by semicolons. |
| Custodian | Identification of the custodian(s) from whom the file was sourced. |
| All Custodians | Identification of all custodians who the producing party agreed to produce and where a duplicate of the Document was de-duplicated when processing the documents. |
| File Path | The file path from which the document was collected |
| All Paths | Identification of all file paths for duplicate copies. |
| Author | Author field extracted from the Metadata of a Document or other creator identified for the Document. |
| From | From field extracted from the Metadata of an email message. |
| To | To field extracted from the Metadata of an email message. |
| Cc | Cc field extracted from the Metadata of an email message. |
| Bcc | Bcc field extracted from the Metadata of an email message. |
| Pages | Total number of pages in the Document. |
| Date Received | Datetime received (MM/DD/YYYY HH/MM/SS). |
| Date Sent | Datetime sent (MM/DD/YYYY HH/MM/SS). |
| Date Created | Datetime created (MM/DD/YYYY HH/MM/SS). |
| Date Modified | Datetime that a Document was last modified (MM/DD/YYYY HH/MM/SS). |
| Last Modified By | Identification of person(s) who last modified a Document. |
| Message Id. | Unique Message Id. |
| FIELD NAME | FIELD DESCRIPTION |
| In Reply To | Message ID of email that instant email is in reply to. |
| Subject | Subject line extracted from an email, e-document or e-attachment. |
| Filename | The full name of the Native File. |
| File Extension | The extension of the file. |
| File Size | The size of the file in bytes. |
| MD5 Hash | The MD5 hash value of a Document. |
| SHA1 Hash | The SHA1 hash value of a Document. |
| Application | Name of the application used to open the file. |
| NativePath | The relative path to the native file for this Document. |
| TextPath | The relative path to the text file for this Document. |
| Redacted | Whether a Document has redactions (Y/N). |
| Placeholder | Whether a Document has a placeholder image (Y/N). |
| Confidentiality | Level of Confidentiality assigned. |
| Track Changes | Document has track changes (Y/N). |
| Hidden Content | Identifies documents with hidden content (i.e. hidden rows, columns, sheets, or slides). |
| Speaker Notes | Document has speaker notes (Y/N). |
| Has Comments | Indicates there are comments in the document. |
| Production Volume | Production volume number (e.g., V001, V002, etc.). |
| Producing Party | Name of party producing the Document. |