IN THE UNITED STATES DISTRICT COURT 

FOR THE EASTERN DISTRICT OF TEXAS 

TYLER DIVISION 

THE DAILY WIRE, LLC, et al., 

 Plaintiffs, 

v. 

UNITED STATES DEPARTMENT OF 

STATE, et al., 

 Defendants. 

§ 

§ 

§ 

§ 

§ 

§ 

§ 

§ 

§ 

§ 

§ 

§ 

Case No. 6:23-cv-609-JDK 

ORDER GRANTING MOTION FOR PROTECTIVE ORDER, CLAWBACK 

AGREEMENT, AND ESI PROTOCOL 

Before the Court is the parties’ joint motion for entry of an agreed-upon 

protective order, clawback agreement, and ESI protocol. Docket No. 63. The Court 

GRANTS the motion. The Court will enter the parties’ proposed protective order and 

clawback agreement as separate orders. The Court ORDERS that the attached ESI 

protocol shall apply to the production of documents in this case. 

So ORDERED and SIGNED this day of

___________________________________

JEREMY D. KERNODLE

UNITED STATES DISTRICT JUDGE 17th June, 2024.

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 1 of 15 PageID #: 2048
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

1

1. Production Format of ESI and Imaged Hard Copy Documents

Responsive ESI and imaged hard copy shall be produced in the format outlined below. All ESI, 

except as outlined below in sections 4 – 15, shall be rendered to TIFF image format, and 

accompanied by an Opticon/Concordance® Image Cross Reference file. All applicable 

metadata/database (see section 2 below) shall be extracted and provided in Concordance® load 

file format. 

a. Image File Format: All documents shall be produced in black and white TIFF 

format unless the image requires color. An image requires color when color in 

the document adds emphasis to information in the document or is itself 

information that would not be readily apparent on the face of a black and white 

image.

b. When producing black and white paper documents scanned to images, or rendered 

ESI, they shall be produced as 300 dpi, 1 bit, single-page TIFF files, CCITT 

Group IV (2D Compression). When producing in color, paper documents 

scanned to images, or rendered ESI, they shall be produced as 300 dpi single-page 

JPG. Images should be uniquely and sequentially Bates numbered and unless 

otherwise specified, Bates numbers should be an endorsement on each image.

i. All TIFF file names shall include the unique Bates number burned into the 

image. (See section 16, below, regarding Bates number instructions.)

ii. All TIFF image files shall be stored with the “.tif” extension.

iii. Images without corresponding extracted text shall be OCR’d using

standard COTS products.

1. An exception report shall be provided when limitations of paper 

digitization software/hardware or attribute conversion do not allow 

for OCR text conversion of certain images. The report shall 

include the DOCID or Bates number(s) corresponding to each such

image. 

iv. All pages of a document or all pages of a collection of documents that 

comprise a folder or other logical grouping, including a box, shall be 

delivered on a single piece of media.

v. No image folder shall contain more than 2,000 images.

c. Opticon/Concordance® Image Cross Reference file: Images should be 

accompanied by an Opticon load file that associates each Bates number with its 

corresponding single-page TIFF image file. The Cross Reference file should also 

contain the relative image file path for each Bates numbered page. The 

Opticon/Concordance® Image Cross Reference file is a page level load file, with 

each line representing one image.

Below is a sample:

REL000000001,,.\IMAGES\001\REL000000001.TIF,Y,,,

REL000000002,,.\IMAGES\001\REL000000002.TIF,,,,

REL000000003,,.\IMAGES\001\REL000000003.TIF,,,,

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 2 of 15 PageID #: 2049
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

2

REL000000004,,.\IMAGES\001\REL000000004.TIF,Y,,,

REL000000005,,.\IMAGES\001\REL000000005.TIF,,,,

The fields are, from left to right:

• Field One – (REL000000001) – the Bates Number. This value must be 

unique for each row in the OPT file. The first page of each document must 

match the DOCID or BEGDOC# value of the respective document.

• Field Two – (blank) – the volume identifier. This field is not required. 

• Field Three – (.\IMAGES\001\REL000000001.TIF) – The relative file 

path to the image to be loaded.

• Field Four – (Y) – the document marker. A “Y” indicates the start of a 

unique document.

• Field Five – (blank) – The folder indicator. This field is not required, and 

typically is not used.

• Field Six – (blank) – The box indicator. This field is not required, and 

typically is not used.

• Field Seven – (blank) – The page count. This field is not required.

d. Concordance® Load File: Images should also be accompanied by a flat, 

document-level load file to provide the metadata and native files containing 

delimited text that will populate fields in a searchable, flat database 

environment. The file encoding must be one of four types: Western European 

(Windows), Unicode (UTF16), Big-Endian Unicode or UTF8. The file should 

contain the required fields listed below in section 2.

1. Text delimited load files are defined using the standard 

Concordance delimiters. For example:

Field Separator ¶ or Code 020

Text Qualifier þ or Code 254

Newline ® or Code 174

Multi-value ; or Code 059

Nested values \ or Code 092

2. This load file should contain the relative file path to the individual 

multi-page, document level text files.

3. This load file should also contain the relative file path to all 

provided native files, such as Microsoft Excel or PowerPoint files.

4. There should be one line for every record in a collection.

5. The load file must contain a header listing the metadata/database 

fields contained within. For example, if the data file consists of a 

First Page of a Record (BegDoc#), Last Page of a Record (ending 

Bates / ENDDOC#), DOCID, DOCDate, File Name, and a Title, 

then the structure may appear as follows:

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 3 of 15 PageID #: 2050
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

3

þBEGDOCþ¶þENDDOCþ¶þDOCIDþ¶þDOCDATEþ¶þFILENAM

Eþ¶þTITLEþ

d. The extracted/OCR text should be provided for each document as a separate 

single text file. The file name should match the BEGDOC# or DOCID for that 

specific record and be accompanied by the .txt extension. 

e. Directory and folder structure: The directory structure for productions should 

be:

\CaseName\LoadFiles

\CaseName\Images < For supporting images (can include subfolders as 

needed, should not include more than 2,000 files per folder)

\CaseName\Natives <Native Files location (can include subfolders as 

needed, should not include more than 2,000 files per folder)

\CaseName\Text <Extracted Text files location (can include subfolders as 

needed, should not include more than 2,000 files per folder)

\CaseName\Translated Images < For supporting images of translated 

documents (as needed for rendered translated documents; can include 

subfolders as needed, should not include more than 2,000 files per folder)

\CaseName\Translated Text <Translated Text files location (as needed 

for translated text; can include subfolders as needed, should not include 

more than 2,000 files per folder).

2. Required Metadata/Database Fields

A “✓” denotes that the indicated field should be present in the load file produced. “Other ESI” 

includes data discussed in sections 4 – 15 below, but does not include email, email repositories 

(section 10), “stand alone” items (section 11), and imaged hard copy material (section 8). Email, 

email repositories, and “stand alone” materials (section 11) should comply with “Email” column 

below. Imaged hard copy materials should comply with the “Hard Copy” column. The parties 

will meet and confer about any field which cannot be populated automatically (i.e. would require 

manual population of information).

Field name Field Description Field 

Type

Field 

Value

Hard 

Copy

EmailOther 

ESI

COLLECTION 

SOURCE

Name of the 

Company/Organization 

data was collected from

Text 160 ✓ ✓ ✓

SOURCE ID (BOX 

#)

Submission/volume/box 

number

Text 10 ✓ ✓ ✓

CUSTODIAN Custodian/Source -

format: Last, First or 

ABC Dept. 

Text 160 ✓ ✓ ✓

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 4 of 15 PageID #: 2051
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

4

Field name Field Description Field 

Type

Field 

Value

Hard 

Copy

EmailOther 

ESI

DUPECUSTODIAN Custodian/Source – all 

custodians who had the 

document before deduplication; format: Last, 

First or ABC Dept.

Text –

semicolon 

delimited

Unlimited ✓ ✓

DUPECUSTODIAN 

FILE PATH

Listing of all the file 

locations of the 

document before deduplication

Text –

semicolon 

delimited

Unlimited ✓ ✓

AUTHOR Creator of the document Text 500 ✓

BEGDOC# Start Bates (including 

prefix) - No spaces

Text 60 ✓ ✓ ✓

ENDDOC# End Bates (including 

prefix) - No spaces

Text 60 ✓ ✓ ✓

DOCID Unique document Bates 

# or populate with the 

same value as Start Bates 

(DOCID = BEGDOC#) 

Text 60 ✓ ✓ ✓

PGCOUNT Page Count Number 10 ✓ ✓ ✓

GROUPID Contains the Group 

Identifier for the family, 

in order to group files 

with their attachments

Text 60 ✓ ✓

PARENTID Contains the Document 

Identifier of an 

attachment’s parent 

Text 60 ✓ ✓

ATTACHIDS Child document list; 

Child DOCID or Child 

Start Bates

Text –

semicolon 

delimited

Unlimited ✓ ✓ ✓

ATTACHLIST List of Attachment 

filenames

Text –

semicolon 

delimited

Unlimited ✓ ✓

BEGATTACH Start Bates number of 

parent

Text 60 ✓ ✓ ✓

ENDATTACH End Bates number of last 

attachment

Text 60 ✓ ✓ ✓

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 5 of 15 PageID #: 2052
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

5

Field name Field Description Field 

Type

Field 

Value

Hard 

Copy

EmailOther 

ESI

RECORD TYPE Use the following 

choices: Image, Loose Email, E-mail, E-Doc, 

Attachment, Hard Copy

or Other. If using Other, 

please specify what type 

after Other

Text 60 ✓ ✓ ✓

FROM Sender (i.e.: e-mail 

address, Last name, First 

name) 

Text 160 ✓ ✓

TO Recipient (i.e.: e-mail 

address, Last name, First 

name) 

Text –

semicolon 

delimited

Unlimited ✓ ✓

CC Carbon Copy Recipients

(i.e.: e-mail address, Last 

name, First name) 

Text –

semicolon 

delimited

Unlimited ✓ ✓

BCC Blind Carbon Copy 

Recipients (i.e.: e-mail 

address, Last name, First 

name) 

Text –

semicolon 

delimited

Unlimited ✓ ✓

SUBJECT Subject line of email Text Unlimited ✓

TITLE Document Title Text Unlimited ✓

CONVINDEX E-mail system ID used to 

track replies, forwards, 

etc.

Text Unlimited ✓

DOCDATE Last Modified Date for 

files and Sent date for email, this field inherits 

the date for attachments 

from their parent. Do 

not provide 00/00/0000.

Date MM/DD/

YYYY

✓ ✓

TEXT FILEPATH Relative file path of the 

text file associated with 

either the extracted text 

or the OCR

Text Unlimited ✓ ✓ ✓

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 6 of 15 PageID #: 2053
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

6

Field name Field Description Field 

Type

Field 

Value

Hard 

Copy

EmailOther 

ESI

DATE TIME SENT Date and time Sent (USE 

TIME ZONE OF 

COLLECTION 

LOCALITY)

Numbers must be 

populated. If date is 

unknown, leave blank. 

Do not provide 

00/00/0000

Date and 

Time

MM/DD/

YYYY

HH:MM:S

S

✓

DATE TIME CRTD Date Created (USE 

TIME ZONE OF 

COLLECTION 

LOCALITY)

Numbers must be 

populated. If date is 

unknown, leave blank. 

Do not provide 

00/00/0000

Date and 

Time

MM/DD/

YYYY

HH:MM:S

S

✓ ✓

DATE TIME SVD Date Saved (USE TIME 

ZONE OF 

COLLECTION 

LOCALITY)

Numbers must be 

populated. If date is 

unknown, leave blank. 

Do not provide 

00/00/0000

Date and 

Time

MM/DD/

YYYY

HH:MM:S

S

✓ ✓

DATE TIME MOD Date Last Modified 

(USE TIME ZONE OF 

COLLECTION 

LOCALITY)

Numbers must be 

populated. If date is 

unknown, leave blank. 

Do not provide 

00/00/0000

Date and 

Time

MM/DD/

YYYY

HH:MM:S

S

✓ ✓

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 7 of 15 PageID #: 2054
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

7

Field name Field Description Field 

Type

Field 

Value

Hard 

Copy

EmailOther 

ESI

DATE TIME RCVD Date Received (USE 

TIME ZONE OF 

COLLECTION 

LOCALITY)

Numbers must be 

populated. If date is 

unknown, leave blank. 

Do not provide 

00/00/0000

Date and 

Time

MM/DD/

YYYY

HH:MM:S

S 

✓

DATE TIME ACCD Date Accessed (USE 

TIME ZONE OF 

COLLECTION 

LOCALITY)

Numbers must be 

populated. If date is 

unknown, leave blank. 

Do not provide 

00/00/0000

Date and 

Time

MM/DD/

YYYY

HH:MM:S

S

✓ ✓

TIME ZONE 

OFFSET

Time zone of collection 

locality, relative to 

Coordinated Universal 

Time (UTC). E.g., for 

US Central Standard 

Time (CST), the value 

for this field should be -

6.0

Decimal 10 ✓

FILE SIZE Native File Size in KBs Decimal 10 ✓

FILE NAME File name - name of file 

as it appeared in its 

original location

Text Unlimited ✓

APPLICATION Application used to 

create native file (e.g. 

Excel, Outlook, Word)

Text 160 ✓ ✓

FILE EXTENSION Extension for the file 

(e.g. .doc, .pdf, .wpd)

Text 10 ✓ ✓

FILEPATH Data’s original source 

full folder path

Text Unlimited ✓ ✓

NATIVE LINK Relative file path 

location to the native file

Text Unlimited ✓ ✓

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 8 of 15 PageID #: 2055
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

8

Field name Field Description Field 

Type

Field 

Value

Hard 

Copy

EmailOther 

ESI

FOLDER ID Complete E-mail folder 

path (e.g. Inbox\Active) 

or Hard Copy container 

information (e.g. folder 

or binder name)

Text Unlimited ✓ ✓

HASH VALUE Identifying value of an 

electronic record that is 

used for deduplication 

during processing. MD5 

or SHA1 hash algorithms 

may be used, but must be 

kept consistent 

throughout all 

productions.

Text Unlimited ✓ ✓

MESSAGEHEADER E-mail header. Text Unlimited ✓

ATTACHMCOUNT Number of attachments 

(any level child 

document) associated 

with a ParentID

Text 10 ✓

FILE TYPE Description that 

represents the file type to 

the Windows Operating 

System. E.g., Adobe 

Portable Document 

Format, Microsoft Word 

97 – 2003, or Microsoft 

Office Word Open XML 

Format.

Text 160 ✓ ✓

HAS HIDDEN 

CONTENT

Identifies whether the 

document has comments, 

track changes or other 

hidden content or data 

associated with it

Text Yes/No ✓ ✓

MESSAGE TYPE Exchange Message class 

or equivalent

Text 60 ✓

EXTENDED 

PROPERTIES 

Text Unlimited ✓ ✓

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 9 of 15 PageID #: 2056
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

9

Field name Field Description Field 

Type

Field 

Value

Hard 

Copy

EmailOther 

ESI

HAS REDACTIONS Identifies whether a 

record has been 

produced with 

redactions; should be 

populated with Y for 

records with redactions 

and N for records 

without redactions. 

Text Yes/No ✓ ✓ ✓

HAS 

TRANSLATIONS

Identifies whether a 

document has been 

produced with translated 

text or audio contains a 

transcript

Text Yes/No ✓ ✓ ✓

3. De-Duplication, Near-Duplicate Identification, Technology Assisted Review, 

E-mail Conversation Threading and Other Culling Procedures

a. De-duplication shall be performed using a similarity function of 95% or greater 

based on content – across all custodians. De-duplication shall also be performed 

on records contained 100% within another record using email threading 

technology. The custodian of each record shall be populated in the 

DupeCustodian field. 

b. All files found on the National Institute of Standards and Technology (NIST) list, 

commonly referred to as deNISTing, should be excluded from delivery. All 

available metadata from files withheld from delivery due to the deNISTing 

process will be available upon request.

c. All files should be globally de-duplicated or de-duplication of exact hash copies 

within a custodian’s data may be done at the family level. If globally deduplicated, the files should be globally de-duplicated with the following 

conditions:

i. The “DupeCustodian” metadata field (listing of all custodians who had the 

document before de-duplication) must be provided with the document 

production.

ii. The “DupeCustodian File Path” metadata field (listing all the file locations of 

the document before de-duplication) must be provided with the document 

production.

iii. All files and metadata for the duplicate documents removed during deduplication must be preserved and available for production upon request.

iv. De-duplication must be done by document family, not by individual 

document.

v. A detailed description of the steps taken to de-duplicate (including the process 

of obtaining hash values) must be provided upon request. For every 

production after the first, a separate Unified Custodian overlay shall be 

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 10 of 15 PageID #: 2057
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

10

provided. If no overlay is necessary due to the fact that no documents deduped out in connection with previously produced documents or because deduplicated custodian information is included in the .dat file for the production, 

this shall be expressly stated in the cover letter accompanying the subsequent 

production(s).

d. The Producing Party shall not use any other technology-based procedure to cull, 

filter, group, separate or de-duplicate, or near-deduplicate, etc. (i.e., reduce the 

volume of) potentially responsive material before discussing with and obtaining 

the written approval of the opposing party. All objective coding (e.g., near 

duplicate ID or e-mail thread ID) shall be discussed and produced as additional 

metadata fields. 

4. Hidden Text

All hidden text (e.g. track changes, hidden columns, mark-ups, notes) shall be expanded and 

rendered in the image file. Except for Adobe PDF files, for any files that cannot be expanded,

the native files shall be produced with the image file. If an Adobe PDF’s hidden text cannot be 

expanded and rendered in an image file, it need only be produced in native form if individually 

requested by a specific document identifier or bates number.

5. Embedded Files and File Links

All non-graphic embedded objects (Word documents, Excel spreadsheets, .wav files, etc.) that 

are found within a file shall be extracted and produced. For purposes of production, the 

embedded files shall be treated as attachments to the original file, with the parent/child 

relationship preserved.

The parties shall meet and confer regarding how to treat file links, including links within e-mails 

to centralized document repositories (e.g. MS OneDrive and Google Drive). 

6. Image-Only Files

All image-only files (non-searchable .pdfs, multi-page TIFFs, Snipping Tool and other 

screenshots, etc., as well as all other images that contain text) shall be produced with OCR text 

and metadata/database fields identified in section 2 for “Other ESI.” 

7. Encrypted Files

Any data (whether individual files or digital containers) that is protected by a password, 

encryption key, digital rights management, or other encryption scheme, shall be decrypted prior 

to processing for production.

a. The unencrypted text shall be extracted and provided per section 1.d. The 

unencrypted files shall be used to render images and provided per sections 1.a and 

1.b. The unencrypted native file shall be produced pursuant to sections 9-15. 

b. If such protected data is encountered but unable to be processed, each file or 

container shall be reported as an exception and shall include all available 

metadata associated with the data, including custodian information. 

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 11 of 15 PageID #: 2058
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

11

8. Production of Imaged Hard Copy Records

All imaged hard copy material shall reflect accurate document unitization including all 

attachments and container information (to be reflected in the PARENTID, ATTACHID, 

BEGATTACH, ENDATTACH and FOLDERID). 

a. Unitization in this context refers to identifying and marking the boundaries of 

documents within the collection, where a document is defined as the smallest 

physical fastened unit within a bundle. (e.g., staples, paperclips, rubber bands, 

folders, or tabs in a binder).

b. The first document in the collection represents the parent document and all other 

documents will represent the children.

c. All imaged hard copy documents shall be produced as 300 dpi single-page TIFF 

files, CCITT Group IV (2D Compression). All documents shall be produced in 

black and white TIFF format unless the image requires color. An image requires 

color when color in the document adds emphasis to information in the document 

or is itself information that would not be readily apparent on the face of a black 

and white image. Images identified as requiring color shall be produced as color 

300 dpi single-page JPEG files.

d. All objective coding (e.g., document date or document author) should be 

discussed and could be produced as additional metadata/database fields should 

they be deemed as necessary.

9. Production of Spreadsheets and Presentation Files 

All spreadsheet and presentation files (e.g. Excel, PowerPoint) shall be produced in the 

unprocessed “as kept in the ordinary course of business” state (i.e., in native format), with an 

associated placeholder image and endorsed with a unique Bates number. See section 16 below. 

The file produced should maintain the integrity of all source, custodian, application, embedded 

and related file system metadata. 

10. Production of E-mail Repositories 

E-mail repositories, also known as e-mail databases (e.g., Outlook PST, Lotus NSF), can contain 

a variety of items, including: messages, calendars, contacts, tasks, etc. E-mail database systems 

should not be produced without consultation with the opposing party about the format for the 

production of such databases.

11. Production of Items Originally Generated in E-mail Repositories but Found 

and Collected Outside of E-mail Repositories, i.e., “Stand-alone” Items 

Any parent e-mail or other parent items (e.g., calendar, contacts, tasks, notes, etc.) found and 

collected outside of e-mail repositories (e.g., items having extensions .msg, .htm, .mht, etc.), 

shall be produced with the “Loose E-mail” metadata fields outlined in section 2, including but 

not limited to any attachments, maintaining the family (parent/child) relationship.

12. Production of Social Media 

Prior to any production of responsive data from social media (e.g., Twitter, Facebook, LinkedIn, 

etc.), the parties shall meet and confer over the potential export formats before collecting the 

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 12 of 15 PageID #: 2059
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

12

information, to ensure it is collected and produced in a way that preserves the original metadata, 

has a clear chain of custody, and provides as much information as possible regarding the source 

and history of each individual communication. 

13. Production of Structured Data 

Production of responsive data from a structured database (e.g., Oracle, SAP, SQL, MySQL, 

QuickBooks, proprietary timekeeping, accounting, sales rep call notes, CRMs, SharePoint, etc.), 

if in the form of a report, should be in comma separated values (.csv) format. If production in a 

report is not feasible, the parties will meet and confer on alternative production formats.3

14. Production of Photographs with Native File or Digitized ESI

Photographs shall be produced as single-page JPEG files with a resolution equivalent to the 

original image as they were captured/created. All JPEG files shall have extracted 

metadata/database fields provided in a Concordance® load file format as outlined in section 2 for 

“Other ESI.”

15. Production of Images from which Text Cannot be OCR Converted

An exception report or other indication shall be provided when limitations of paper digitization 

software/hardware or attribute conversion do not allow for OCR text conversion of certain 

images. The report shall include the DOCID or Bates number(s) corresponding to each such 

image. 

16. Production of Native Files (When Applicable Pursuant to These 

Specifications)

Production of native files, as called for in these specifications, shall have extracted 

metadata/database fields provided in a Concordance® load file format as defined in the field 

specifications for “Other ESI” as outlined in section 2 as well as a placeholder image which 

indicates a native file is being produced.

ESI shall be produced in a manner which is functionally usable. The following are examples:

a. AutoCAD data, e.g., DWG and DXF files, shall be processed/converted and 

produced as single-page JPG image files and accompanied by a Concordance® 

Image formatted load file as described above. The native files shall be placed in a 

separate folder on the production media and linked by a hyperlink within the text 

load file.

b. GIS data shall be produced in its native format and be accompanied by a viewer 

such that the mapping or other data can be reviewed in a manner that does not 

detract from its ability to be reasonably understood.

c. Audio and video recordings shall be produced in native format and be 

accompanied by a viewer if such recordings do not play in a generic application 

(e.g., Windows Media Player).

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 13 of 15 PageID #: 2060
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

13

17. Bates Number Convention 

All images should be assigned Bates numbers before production. Each Bates number shall be a 

standard length, include leading zeros in the number, and be unique for each produced page. The 

numbers should be endorsed on the actual images at a location that does not obliterate, conceal, 

or interfere with any information from the source document. Native files should be assigned a 

single Bates number for the entire file which will represent the native document in the Opticon/ 

Concordance® Image Cross Reference file. The load file will include a reference to the native 

file path and utilize the NATIVELINK metadata field). The Bates number shall not exceed 30 

characters in length and shall include leading zeros in the numeric portion. The Bates number 

shall be a unique number given sequentially (i.e. page one of document is PREFIX0000000001, 

page two of the same document is PREFIX0000000002) to each page (when assigned to an 

image) or to each document (when assigned to a native file). In the event of rolling productions, 

the numbering convention shall remain consistent throughout the entire production. There shall 

be no spaces between the prefix and numeric value. If suffixes are required, please use “dot 

notation.” Below is a sample of dot notation:

Document #1 Document #2

Page #1 PREFIX00000000001 PREFIX00000000002

Page #2 PREFIX00000000001.002 PREFIX00000000002.002

Page #3 PREFIX00000000001.003 PREFIX00000000002.003

18. Other Production Formats

If other ESI or document production formats are required but are not included in these 

specifications, the parties shall confer on the specific technical production specifications required 

prior to production. 

19. Media Formats for Storage and Delivery of Production Data

Electronic documents and data shall be delivered on any of the following media:

a. CD-ROMs and/or DVD-R (+/-) formatted to ISO/IEC 13346 and Universal Disk 

Format 1.02 specifications; Blu-ray.

b. External hard drives (USB 3.0 or higher, formatted to NTFS format 

specifications) or flash drives

c. Government approved File Transfer Protocol (FTP) technologies.

d. Storage media used to deliver ESI shall be appropriate to the size of the data in 

the production.

e. Media should be labeled with the case name, production date, Bates range, and 

producing party.

20. Virus Protection and Security for Delivery of Production Data

Production data shall be free of computer viruses. Any files found to include a virus shall be 

quarantined by the producing party and noted in a log to be provided to the opposing party. 

Password protected or encrypted files or media shall be provided with corresponding passwords 

and specific decryption instructions. 

Case 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 14 of 15 PageID #: 2061
Specifications for Production of ESI and Digitized (“Scanned”) Images

(“Production Specifications”)

14

21. Compliance and Adherence to Generally Accepted Technical Standards

Production shall be in conformance with standards and practices established by the National 

Institute of Standards and Technology (“NIST” at www.nist.gov), U.S. National Archives & 

Records Administration (“NARA” at www.archives.gov), American Records Management 

Association (“ARMA International” at www.arma.org), American National Standards Institute 

(“ANSI” at www.ansi.org), International Organization for Standardization (“ISO” at 

www.iso.org), and/or other U.S. Government or professional organizations.

22. Read Me Text File

All deliverables shall include a “read me” text file at the root directory containing: total number 

of records, total number of images/pages or files, mapping of fields to plainly identify field 

names, types, lengths, and formats. The file shall also indicate the field name to which images 

will be linked for viewing, date and time format, and confirmation that the number of files in 

load files matches the number of files produced.

23. Transmittal Letter to Accompany Deliverables 

All deliverables should be accompanied by a transmittal letter including the production date, case 

name and number, producing party name, and Bates range produced. Technical instructions on 

how to decrypt media should be included in the transmittal letter but the password should be 

transmitted separately.

-XXXCase 6:23-cv-00609-JDK Document 64 Filed 06/17/24 Page 15 of 15 PageID #: 2062