IN RE: Bard Implanted Port Catheter Products Liability Litigation MDL No. 3081 IN THE UNITED STATES DISTRICT COURT FOR THE DISTRICT OF ARIZONA Filed November 22, 2023 CASE MANAGEMENT ORDER NO. 12 ESI ORDER (Applies to All Actions) THIS MATTER, having come before the Court upon the joint submission by the parties (Doc. 95), IT IS ORDERED: This ESI Order (“Order”) shall govern the production of electronically stored information (“ESI”) and (“hard copy”) paper documents. This Order and the Protective Order (Case Management Order No. 11) apply to all future productions in this Multi-District Litigation (“MDL”), including all cases transferred to this Court in the original Transfer Order from the Judicial Panel on Multidistrict Litigation, those subsequently transferred as tag-along actions, and all cases directly filed in or removed to this MDL in the future as well any appeal therefrom. In the event of transfer to other courts, this Order will remain in effect in all respects until adopted by the transferee court or replaced by a subsequent order. Unless more specifically addressed by the terms of this Order, this action remains subject to the relevant provisions of the Federal Rules of Civil Procedure and the Local Rules governing the production of documents and ESI. The terms of this Order neither enhance nor diminish the scope of discovery as contemplated by the Rules. I. DEFINITIONS. A. The term “Action” or “MDL” means the above captioned matter, and all individual matters that have be transferred to this Court. B. The term “Electronically Stored Information” (hereinafter, “ESI”) has the same meaning as contemplated by Rule 34 of the Federal Rules of Civil Procedure. C. The term “Document” has the same meaning as contemplated by Rule 34 of the Federal Rules of Civil Procedure, and such meaning includes, in context, a discrete file of ESI that corresponds to such a writing. As used in this Order, the term “Document” or Documents” includes both ESI and Hard Copy Documents. D. “Hard Copy Document” means a document that does not exist as ESI. E. “Metadata” means information about information, or data about data, and includes, without limitation: (i) information embedded in or associated with a native file that is not ordinarily viewable or printable from the application that generated, edited, or modified such native file; (ii) information generated automatically by the operation of a computer or other information technology system when a native file is created, modified, transmitted, deleted or otherwise manipulated by a user of such system; (iii) information about a file, whether created by a user or generated by the system itself; or (iv) information about a record or Document in a document management system, whether manually created by a user or generated by the system itself. F. “Native,” “Native format,” or “Native data format” means the format of ESI in which the ESI was originally created or the format used by the Producing Party in the usual course of the Producing Party’s business activities. G. “Extracted Text” means the information created by segregating the textual content of an ESI native source into a separate electronic text file. H. “Optical Character Recognition” or “OCR” means the process of recognizing the visible text contained within a Hard Copy Document or contained within the digital image of a Document, and rendering the recognized text into an electronic text file. I. “Searchable Text” means extracted text or electronic text created by OCR. J. “Processing” means the preparation of collected ESI for ingestion into an evidence management platform. It includes the automated ingestion of collected ESI into a program for the purpose of extracting metadata and text (and in some cases, the creation of a static image of the source ESI) according to a predetermined set of specifications. K. “Culling” means the exclusion or elimination of ESI from a collection of potentially responsive information by the application of filtering criteria. In a given document production workflow, culling eliminates a class of ESI from any subsequent consideration for responsiveness. An example of culling would be the elimination of system generated files types included in the database maintained by the National Institute of Standards and Technology (the “NIST List”), or the elimination of ESI created before or after a specific date. L. “Custodians” means current and/or former employees of Defendants who are reasonably likely to have relevant Documents or ESI. M. “Custodial File” means Documents or ESI maintained in Custodian-specific sources. Examples of Custodial File locations include: the Custodian’s Company issued computer (desktop and/or laptop), Documents in the Custodian’s OneDrive account if applicable, and e-mail maintained in the Custodian’s Company email account, e-mail archive and/or PSTs if applicable. To the extent a Producing Party identifies any other source of custodial data that contains unique, discoverable Documents or ESI, it shall be included in the Custodial File to the extent reasonably practicable. N. “Non-Custodial Sources” means information sources that are not associated with a single Custodian but rather are managed or accessed by multiple persons, e.g. shared areas, databases, document management systems, shared drives, collaboration platforms, etc. O. “And” and “or” shall be construed conjunctively or disjunctively as necessary to make their use inclusive rather than exclusive, e.g., “and” shall be construed to mean “and/or.” “Include” and “Including” shall be construed to mean “include but not be limited to” and “including, but not limited to.” Reference to the singular shall also be deemed to refer to the plural, and vice-versa. All other unique terms have the meaning described in The Sedona Conference Glossary: E-Discovery and Information Management (4th ed. Apr. 2014). II. GENERAL PROVISIONS A. Scope The procedures and protocols outlined in this Order govern the production of Documents and ESI in this Action. For any other materials, the Parties shall meet and confer regarding the form and format of production for specific items or categories of items. Nothing in this protocol shall limit a party’s right to seek or object to discovery as set out in the applicable Rules, or to object to the authenticity or admissibility of any Documents or ESI produced in this Action. All objections to the discoverability or admissibility of any Documents or ESI produced are preserved and may be asserted at any time in accordance with the Federal Rules of Civil Procedure, Local Rules governing the production of Documents or ESI, and the Federal Rules of Evidence. Nothing in this Order shall be deemed to prevent the Parties from agreeing to terms different than or inconsistent with the terms of this Order, nor shall a Party be prevented from seeking to amend this Order. B. Cooperation and Discovery Dispute Resolution; Interpretation The fundamental purpose served by this Order is to promote the exchange of discoverable information in an efficient and economical manner. The Parties shall conduct discovery in a cooperative and collaborative manner, including without limitation, by drafting reasonable and proportional discovery requests and responses, and by meeting and conferring in good faith on unforeseen or disputed issues that may arise during the course of discovery. When a request for conference and collaboration about an issue is made by one Party to another, the conference and collaboration should occur without unreasonable delay. To the greatest extent possible, the conference participants should include those persons with authority to make ultimate decisions concerning disposition of the matter. At the conclusion of any unsuccessful attempt to resolve a disputed discovery issue, and prior to scheduling a call with the Court to address, the Parties should have identified the scope of the issues as narrowly and accurately as possible. C. Designated ESI Liaison Each side shall designate one or more individuals as Designated ESI Liaison(s) for purposes of meeting and conferring with the other Parties and of attending Court hearings on the subject of relevant ESI. The initial ESI Liaison designated for the Plaintiffs is Chad S. Roberts, Esq. The initial ESI Liaison designated for the Defendants is Makenzie Windfelder, Esq. D. No Designation of Discovery Requests The Parties will produce Documents and ESI in a reasonably usable and searchable format as set forth herein. A Producing Party shall not be required to organize or label Documents or ESI to correspond to specific discovery requests. E. Backup Tapes Absent a showing of good cause by the Requesting Party, no Party shall be required to modify or suspend procedures, including rotation of backup media, used in the normal course of business to back up data and systems for disaster recovery purposes as the presumptive burden or expense of such discovery is likely to outweigh any evidentiary benefit. III. IDENTIFICATION AND COLLECTION OF SOURCES OF DOCUMENTS AND ESI A. Sources The Parties shall confer regarding the identification and collection of sources of relevant Documents and ESI, including the sources and scope of information, Documents, ESI, and other material to be produced by Plaintiffs, as well as Defendants’ Custodians and Non-Custodial Sources (collectively “Sources”) likely to possess relevant information. The Parties shall also confer regarding third-party Documents and ESI. B. Collection The Parties represent that ESI will be collected in a manner that best preserves its original state without any alteration or destruction of either the underlying data or its reasonably available metadata. Where uncertainty may exist concerning a particular collection methodology, the parties shall initiate a meet and confer process. IV. PROCESSING, CULLING, AND DE-DUPLICATION OF ESI A. Processing Protocols1. Time Zone. When processing ESI, Universal Coordinated Time (UTC) shall be selected as the time zone.2. Dynamic Fields. Files containing dynamic fields such as file names, dates, and times should be processed for production showing the field code (e.g. “[FILENAME]” or “[AUTODATE]”), rather than the values for such fields existing at the time the file is processed.3. Compressed Files. The Producing Party shall attempt to decompress file types (e.g. .CAB, .GZ, .TAR. .ZIP) in a reiterative manner to ensure that a compressed file within a compressed file is decompressed into the lowest possible compression resulting in individual files. Original compression files need not be produced, provided the responsive content files are produced.4. Embedded Objects. Some Microsoft Office and .RTF files may contain embedded objects. Such objects typically are the following file types: Microsoft Excel, Word, PowerPoint, Project, Outlook, Access, and PDF. Subject to claims of privilege and immunity, as applicable, embedded objects that are one of the identified file types shall be extracted as separate files and shall be produced as attachments to the file in which they were embedded unless the parent Document is produced in native format in which case the embedded information is contained within it and therefore does not need to be separately produced. If embedded objects are privileged or require redaction, both the parent Document and embedded file will be produced in TIFF format. If embedded objects are non-substantive graphic files such as corporate logos, such embedded objects need not be produced as separate Documents as their content is visible in the parent Document.5. Encrypted Files. The Producing Party will take reasonable steps to unencrypt discoverable ESI that exists in encrypted format (e.g., because password-protected) and will produce responsive, non-privileged Documents that can be reasonably unencrypted. If a producing party cannot unencrypt discoverable electronically stored information that exists only in encrypted format, the parties agree to meet and confer regarding how such information should be handled as well as whether cost shifting may be appropriate.6. Technical Issues. If a member of a Document family that has otherwise been determined to be responsive cannot be technically processed (e.g., unsupported file format, file corruption, inaccessible password protected Document), the Document shall be produced with a Bates-labeled slip sheet that states “Technical issue—file cannot be processed.” The associated metadata for the Document with the technical problem shall be preserved and, where technically possible, produced. For Documents that convert with errors to TIFF (e.g., oversized drawings, CAD renderings, picture files, etc.), the Producing Party may produce in native format unless the Document contains redactions.7. Translation Software. Responsive Documents and ESI shall be produced in its original language without translation or alteration. The Parties may utilize translation software for internal review of Documents and ESI identified as potentially privileged by application of the Producing Party’s privilege filter. The Parties do not intend to waive privilege or Confidentiality designations as outlined in the Protective Order, for inadvertent production of such information. Any and all Documents or ESI produced containing foreign language remain subject to and are governed by the terms of the Protective Order. B. De-Duplication1. A Producing Party may employ global de-duplication (i.e., both within a particular source and across all sources) provided it complies with the requirements of this section. The Producing Party need produce only a single copy of responsive duplicative ESI. ESI will be considered duplicative if it has matching MD5 or SHA-1 hash values. For this purpose, file contents only may be used for MD5 or SHA1 Hash value calculation and will not require inclusion of operating system metadata (e.g., filename, file dates) values. Entire Document families may constitute duplicate ESI. De-duplication shall not break apart families. When the same duplicate ESI exists in the files of multiple Custodians, those persons shall be listed in the “ALL CUSTODIANS” field identified in Appendix 2. For emails with attachments, or loose files with embedded files extracted as separate records during the initial processing, the hash value is to be generated based on the parent/child Document grouping, meaning that emails shall be treated as duplicates only if they are identical both in their bodies and in all their attachments.Where a duplicative Document (or Document family) is possessed by multiple Custodians/Sources of a Producing Party and the Party produces a single copy of that Document, the Party shall produce the metadata identifying all Custodians/Sources that possessed a duplicate copy of the Document in the “ALL CUSTODIANS” field in the production load file. When the “ALL CUSTODIANS” value has changed for records already produced, based on additional data being loaded and compared to previously produced data, the Producing Party shall provide an overlay file for Documents with a changed value, e.g. a “Duplicate Custodian Overlay.” The Producing Party may provide the Duplicate Custodian Overlay with each subsequent production, or at reasonable regular intervals. C. Email Threading1. A Producing Party may employ electronic mail thread suppression in the manner specified in this Order. As used in this Order, email thread suppression means reducing duplicative production of email conversation threads by producing only the most recent or most complete email containing the prior thread of emails, as well as all attachments appended at any point within the history of the thread, and excluding emails constituting exact duplicates of prior email text within the produced string.2. To qualify as a single email conversation thread, all lesser included individual messages must have identical message conversation participants (including “bcc:” blind copy participants) and attachment history. The inclusion or deletion of a message participant shall terminate a conversation thread for this purpose, but such an occurrence (“conversation branching”) may create the beginning of a separate and distinct conversation thread containing some or all of the lesser included messages. Each Party may produce (or list on any required privilege log) only the most inclusive email threads as long as the most inclusive email thread includes all non-produced emails (including attachments) that are part of the same string. If a portion of an email thread is privileged or otherwise protected from disclosure, the Producing Party shall redact the privileged content and produce the non-privileged portion of the thread. D. Culling of Identified Data Sets 1. System Files may be culled by de-NISTing. An electronic file collection may be “de-NISTed” at the Producing Party’s option, by removing commercially available, non-user created operating system and application files contained on the National Institute of Standards and Technology (“NIST”) file list. Identification of NIST list matches will be through MD5 or SH-1 Hash values.2. The Parties shall meet and confer regarding the Culling method(s) a Producing Party has determined to apply to its sources to identify potentially relevant ESI for review, including but not limited to use of a date range, or running of keyword search terms across Sources likely to contain relevant Documents or ESI. Similarly, if a Party elects to employ analytics, machine learning, or generative AI technologies instead of keyword search terms to identify potentially responsive content, the Parties will meet and confer regarding the methodologies used.In the event a Producing Party determines it will apply keyword and/or Boolean searches to its sources, it shall provide the Requesting Party with the searches it proposes running across its relevant sources. The Parties will meet and confer in good faith in an iterative and collaborative process to determine if the Producing Party’s searches should be supplemented with additional narrowly tailored and proportional keyword or Boolean searches to identify responsive Documents or ESI. In the event a Producing Party objects to inclusion of a requested term as overly broad, disproportionate, or returning a large volume of false hits, the Producing Party shall share a hit report with the Requesting Party that identifies the number of Documents the contested term will add to the review universe. The Parties shall confer in good faith as to reasonable and proportionate refinements to the contested term.Where a Source is not readily searchable using keyword search terms, the Producing Party shall employ a reasonable and appropriate search and retrieval method, considering the nature of the source and consistent with the Party’s discovery obligations under the Federal Rules. 3. The fact that any ESI has been identified by Culling methodologies shall not prevent the Producing Party from conducting responsiveness review or from withholding a Document or ESI from production pursuant to the terms of the Protective Order. V. PRODUCTION FORMAT The Parties shall produce Documents and ESI in a reasonably usable form as set forth below. The parties may encounter information sources for which the traditional notion of a “document” or a “page” is not meaningful. A Producing Party may initiate a meet and confer conference to address the format of production for any such information source, but in any event will make reasonable good faith efforts to produce the information in a format that is otherwise as reasonably consistent to the greatest degree possible with the production format specified in this order. A. Presumptive Format of Production for Non-structured Information Sources1. Document Images, with Metadata, Text, and Native Files: Subject to the specifications or exceptions set forth below, the presumptive format for production of Documents is as a group of single page TIFF image files accompanied by metadata as set forth in Appendix 2, and a document level searchable text file. The following file types shall be produced in native format: electronic spreadsheets (e.g., Microsoft Excel), electronic presentations (e.g., Microsoft PowerPoint), audio/visual media files, and non-embedded image files, except to the extent that any such file requires redaction in which case the file shall be converted to TIFF, redacted, and the underlying native file withheld. (Electronic spreadsheets may be redacted in native format to preserve their utility.) Files produced solely in native format (e.g., .xls, .ppt, .wav, .mpeg-4, .mov, .jpeg, etc.) will be produced with a TIFF image slip sheet indicating the production number of the native file and the confidentiality designation, and stating “Produced in Native Format.” The native file name nomenclature will correspond to the same Bates number nomenclature of the corresponding TIFF image slip sheet, as more specifically described in Appendix 5.2. Ancillary Content Disclosed: TIFF images will be rendered in such a way as to show, as may be applicable, all disclosable reviewer’s comments, tracked changes, speaker’s notes, and other similar content.3. Parent-Child Relationships Preserved: The parent-child relationship of ESI, that is the relationship between attachments, enclosures, embedded files, and/or exhibits to their parent Document shall be preserved. The child Document should be consecutively produced immediately after the parent Document. Subject to the obligations set forth in FRCP 26(g)(1), a Producing Party need not produce non-relevant child Documents. If the parent or child is privileged, or if a child Document is non-relevant, a slip sheet bearing the appropriate language will be inserted in the production. Child Documents will be mapped to their parent Document by attachment range within the applicable load file.4. Color When Necessary: When ESI that is to be produced in native form pursuant to this Order is produced without its native file because of applied redactions, and the absence of color in the Document’s TIFF rendering compromises the Requesting Party’s ability to discern the remaining information it contains, the Producing Party will honor reasonable requests to supplement the production with color images.5. Imbedded Links: The Parties are meeting and conferring regarding the scope of production of imbedded hyperlink files.6. Appendices: Additional technical specifications for production format are set forth in the attached appendices (Appendix 1: TIFF Image File Specifications; Appendix 2: Data Load File Specifications; Appendix 3: Searchable Text File Specifications, Appendix 4: Image Load File Specifications; Appendix 5: Native File Specifications). B. Production Format for Hard Copy Documents The scanning of original Hard Copy Documents does not otherwise require that the scanned images be treated as ESI. In scanning and producing Hard Copy Documents, such Documents shall be unitized and organized as they are kept in the normal course of business. The Parties will make relevancy and production determinations for Hard Copy Documents at the Document level. For Hard Copy Documents found in file folders and other physical containers that have labels or tabs or other identifying information, such labels and all sides of such file folders and tabs shall be scanned. In the case of an organized compilation of separate Hard Copy Documents – for example, a binder containing several separate Hard Copy Documents behind numbered tabs − the Document behind each tab should be scanned separately, but the relationship among the Documents in the binder should be reflected in proper coding of the beginning and ending Document and attachment fields. For Hard Copy Documents that contain fixed notes, the pages will be scanned both with and without the notes and those pages will be treated as part of the same Document. Hard Copy Documents will be unitized at the lowest possible level and attachment information preserved. For example, if a folder contains two Hard Copy Documents, the folder and each Document will constitute a separate Document, but they will have the same attachment start and end. If more than one level of parent-child relationship exists, Documents will be kept in order, but all will be treated as children of the initial parent Document. C. Redactions and Production of Redacted Documents The Producing Party may redact from any TIFF image, native file, or metadata field, information that contains Protected Health Information (PHI); protected patient of voluntary reporter information; Personally Identifiable Information (PII); non-relevant Other Product Information as defined in the Protective Order; information that is privileged or protected from discovery as work product or any other applicable privilege or immunity; information subject to non-disclosure obligations imposed by governmental authorities, privacy regulations; or information that is otherwise specifically protected against disclosure by separate order of the Court, the Producing Party may apply redactions to the TIFF image file and produce the Document in redacted form. Any redactions shall be clearly indicated on the produced Document, either with “Redacted” or the redaction reason on the face of the Document if space allows. For Documents produced in native format pursuant to Section V.A.1. of this Order, the corresponding native file of the Document may be withheld from production. Given that the Requesting Party will have the benefit of the context provided by the unredacted portions of a Document, along with non-privileged email header information that is visible on the face of a Document, Documents containing redactions need not be logged on the Producing Party’s privilege log or otherwise provided the redaction reason is indicated on the face of the Document if space allows (e.g.: AC Privilege, PII, etc.) along with a metadata field in the .dat file that identifies the type(s) of redactions that appear on a Document. D. Enterprise Databases If responsive information is identified in a Party’s enterprise or relational database (e.g., Oracle, SQL Server, DB2) and can be produced in an already existing and reasonably available report form, the information may be produced in that report form, in the reasonably usable TIFF-image format or as a spreadsheet, as may be applicable. If an existing report form is not reasonably available, the Parties will meet and confer to attempt to identify a mutually agreeable and proportional report form. E. Document Management Systems or Enterprise Content Management (ECM) Platforms Where legacy Hard Copy Documents and writings have been scanned into a document management system and stored as image files, or where ESI Document files are assembled or maintained within the framework of an ECM or document management system (i.e., Documentum®, OpenText®, etc.), the ESI source may have hybrid features of both structured data and unstructured data. Should Documents managed by any such document management system be identified for production, the Parties shall meet and confer regarding which database fields from the corresponding database record, if available, shall be produced as well as the format of production of such fields. F. Undue Burden or Cost for a Producing Party If the provisions outlined in this Order present an undue burden or cost for a Producing Party, the Parties shall meet and confer to try to agree on a reasonable, alternative form of production. Nothing within this Order prohibits a Party from seeking relief from this protocol pursuant to the Federal Rules of Civil Procedure and the Local Rules governing the production of Documents or ESI. VI. CONVEYANCE AND DELIVERY A. ESI productions may be conveyed by a secure File Transfer Protocol (“SFTP”) or other similar service, or on physical storage media (with standard PC compatible interface), or readily accessible computer or electronic media as the Parties may hereafter agree upon (the “Production Media”). Productions in transit should be encrypted. Each item of Production Media should include: (1) the name of the Producing Party; (2) the production date; (3) a unique sequential production volume name; (4) the Bates number range of the materials contained on such Production Media item; and (5) any additional description of the items the Producing Party deems appropriate. The Production Media shall be accompanied by a transmittal letter identifying the above-described information. B. The Parties will employ commercially appropriate standards for the security, protection, and safeguarding of all productions in this Action. Any subsequent transmission of Documents or ESI received during the course of the Action shall be encrypted. VII. ADDITIONAL PROCEDURES FOR NATIVE FORM FILES Any party seeking to use, in any proceeding in this Action, ESI produced in native form shall do so subject to the following: The Receiving Party shall ensure that if the Document or ESI is disclosed or printed in whole or in part, the native file’s corresponding TIFF slip sheet that bears the Document’s Bates number and confidentiality designation will be included in the disclosure or appended to the native file. At deposition, trial, or in motion practice, if the native file is used, the exhibit or hardcopy rendering of the Document must include the TIFF slip sheet for identification purposes. Use of a file in native form or use of a TIFF image or Hard Copy Document representing the original native-form file shall constitute a representation that the file being used is an accurate, unaltered and complete depiction of the original native-form file as produced by the Producing Party. A. Summaries, Extracts, Excerpts, and Reports Created from Native File Data. Subject to the limitations set out below, the Parties are permitted to create from produced native files summaries, extracts, excerpts, or reports to use as deposition exhibits. To the extent any Party intends to use a summary, extract, excerpt, or report of a native file shall disclose in writing, at the time of use, a description of how the summary, extract, excerpt or report of a native file was created. As applicable, the description should identify the query run and the source data set, or must identify by Bates number the spreadsheet and the columns and rows extracted, or other similar description of the information extracted and how it was extracted. The writing describing the methodology shall be marked as an exhibit. Nothing in this protocol waives the right of any Party to object on any and all grounds to use in any proceeding in this Litigation of a native file, of any altered native file, of any slip sheet or TIFF image associated with the native file, or of any summary, extract, excerpt, or report of a native file. VIII. PRIOR PRODUCTIONS IN OTHER RELATED MATTERS The Parties acknowledge that prior to consolidation of this MDL, Defendants previously collected, processed and produced Documents and ESI in other Implantable Port Products liability litigation that may be of interest in this matter. The Parties shall meet and confer regarding the scope of Documents or ESI Defendants will re-produce in this Action. Defendants shall not be required or obligated to redo or reproduce such discovery to the extent there are differences between the order governing the prior production and this Order. IX. PROCESSING OF NON-PARTY DOCUMENTS A. A Party that issues a non-Party subpoena (“Issuing Party”) shall include a copy of this ESI Protocol with the subpoena and request that the non-Party produce Documents or ESI in accordance with the specifications set forth herein. B. The Issuing Party is responsible for producing to all other Parties any Documents or ESI obtained pursuant to a subpoena to any non-Party in the form in which they were produced by the non-Party. To the extent practical given the data volume, productions by a non-Party should be produced by the Issuing Party to all other Parties within seven days of the non-Party’s production to the Issuing Party. C. Nothing in this Order is intended to or should be interpreted as narrowing, expanding, or otherwise affecting the rights of the Parties or non-Parties to object to a subpoena. Appendix 1: TIFF Image File Specifications TIFF image files created for this litigation pursuant to this Order shall comport with the following specifications: The TIFF image file shall be a Group IV compression, black-and-white, single-page TIFF image file using a 300 x 300 dots-per-inch (DPI) optical scan resolution and an 8.5-inch page size, except for Documents that in the Producing Party’s reasonable judgment require a different resolution or page size. Original Document orientation should be maintained to the extent programmatically feasible (i.e. an original landscape Document should be produced in landscape format). Each TIFF image file shall be branded with a legible, unique Bates number in the lower right corner, positioned so as not to interfere with reading the Document. The Bates number shall: (1) be unique across the entire Document production; (2) be a combination of an alphabetic prefix along with an 8-digit number (e.g. ABC00012345), wherein the numeric portion shall be zero-padded leftwards as needed to comprise 8 digits, (3) contain no special characters or embedded spaces, and (4) be numerically sequential within a given Document. If a production number or set of production numbers is skipped, the skipped number or set of numbers will be communicated to the receiving party. Confidentiality designations, if any, will be branded on the lower left corner of the applicable image, also positioned so as not to interfere with reading. The resulting TIFF image file shall be named according to the naming convention number.TIF, where “number” is the Bates number of the corresponding page. File names for these files shall not contain any special characters or embedded spaces. Image files shall be grouped in folders on the production media of no more than 1,000 TIFF files each unless necessary to prevent a file from splitting across folders. Files will not be split across folders, and separate folders will not be created for each file. Appendix 2: Data Load File Specifications The data load file is a delimited text file containing data about each Document needed for use with standard litigation support software. The file name of the data load file should contain the volume name of the production media, although additional description information may be provided after the volume name. For example, both “ABC001.dat” and “ABC001_metadata.dat” would be acceptable names for a data load file having a production volume named “ABC001.” File names shall not contain any special characters or embedded spaces. Unless other delimiters are specified, the data in each field should be separated using Concordance default delimiters. A semicolon should be used as a multi-entry separator. A carriage-return line- feed should be used to indicate the start of the next record. Any delimited text file containing fielded data must contain in the first line of the data load file each field name, separated by a delimiter, corresponding to the order in which the data appears in the file. Load files should not span across media (e.g. hard drives, etc.); a separate volume should be created for each piece of media delivered. Data for Documents shall normally be produced in only one data load file throughout the productions, unless that Document is noted as being a replacement Document in the Replacement field of the data load file. When it may become necessary to either alter or supplement the metadata associated with previously produced Documents (e.g. Duplicate Custodian Overlay), a Producing Party will clearly and unambiguously advise in the transmittal correspondence whether the production is supplemental (intended to append existing metadata in the Receiving Party’s possession) versus data which is intended to replace existing metadata. Metadata Fields to be Included in the Data Load File For all Documents produced, the following metadata fields for each Document, if available at the time of collection and processing and unless such metadata fields are protected from disclosure by attorney-client privilege or work-product immunity or otherwise prohibited from disclosure by law or regulation, including but not limited to the European Data Privacy Regulation, will be provided in the data load file as set forth in the chart, except to the extent that a Document has been produced with redactions. The term “Scanned Docs” refers to Documents that are in paper form at the time of collection and have been scanned into TIFF images (i.e., “Hard Copy Documents” as defined above.) The term “Email and E-Docs” refers to files that are in electronic form at the time of their collection. *Field designations are friendly names for ease of reference. Actual column names in load files may differ so long as the column names are consistent across the Producing Party’s production and have the same meaning as the fields above. Appendix 3: Searchable Text File Specifications The Document level searchable text file will contain any text in the respective Document, omitting any text redacted from the produced Document. The file naming convention for the text file shall be in the form number.TXT, where “number” is the same Bates number as the Beginning Production Number for the first page of the respective Document images. File names shall not contain any special characters or embedded spaces. The full path and file name of the text file must be provided in the data load file as specified in Appendix 2. OCR text for scanned images of Hard Copy Documents should be generated by applying optical character recognition processes to the image of the Document. The Parties will endeavor to generate accurate OCR and will utilize quality OCR processes and technology. OCR shall be performed on a Document level and provided in Document-level multi-page UTF-8 text files. OCR text should not be delivered in the data load file or any other delimited file. For electronic files, searchable text shall be extracted from the native file and included in the Document-level text file. If the electronic file has no extractable text (e.g. a non-searchable PDF image file), the Document will be OCR’d, and file-level OCR text will be provided in lieu of extracted text. Extracted text shall likewise be produced in Document-level multi-page UTF-8 text files. For files produced in native form, to the extent that it is available, the original file text shall be provided in a Document-level multi-page UTF-8 text file with a text path provided in the *.dat file; otherwise the text contained on the slip sheet shall be provided in the text file with the text path provided in the *.dat file. Appendix 4: Image Load File Specifications The image load file should be a Standard Opticon formatted load file (.opt text file) with ANSI/Western European encoding that references the Control ID on a page level consistent with ingestion into the kCura Relativity® review platform. The name of the image load file should mirror the name of the delivery volume, and should have an .OPT extension (e.g. ABC001.OPT). File names shall not contain any special characters or embedded spaces. The volume names should be consecutive (e.g. ABC001, ABC002, etc.). Every image in the delivery volume should be contained in the image load file, one row in the load file per TIFF image. The total number of Documents referenced in the image load file should match the total number of designated Documents in the data load file for that production. 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. Appendix 5: Native File Specifications For each native file produced, the production will include a TIFF image slip sheet indicating the production number of the native file, the confidentiality designation, and state “Produced in Native Format.” The file naming convention for the native file shall be in the form number.EXT, where “number” is the first page Bates number for the corresponding TIFF image and “EXT” is the original native file extension (i.e., .doc, .xls, .ppt, etc.) File names shall not contain any special characters or embedded spaces. The full path and file name of the native file must be provided in the data load file as specified in Appendix 2.