Cape Fear Public Utility Authority v. The Chemours Company FC, LLC et al

Filing 88

STIPULATION AND ORDER ON DISCOVERY OF ELECTRONICALLY STORED INFORMATION - Signed by US Magistrate Judge Robert T. Numbers, II on 10/11/2019. (Sellers, N.)

UNITED STATES DISTRICT COURT
EASTERN DISTRICT OF NORTH CAROLINA
SOUTHERN DIVISION
CAPE FEAR PUBLIC UTILITY AUTHORITY,
Plaintiff,
v.
Civil Action No. 7:17-CV-00195-D
THE CHEMOURS COMPANY FC, LLC, et al.,
Defendants.

BRUNSWICK COUNTY, LOWER CAPE
FEAR WATER & SEWER AUTHORITY, and
TOWN OF WRIGHTSVILLE BEACH,
Plaintiffs,
Civil Action No. 7:17-CV-00209-D
v.
E.I. DU PONT DE NEMOURS AND
COMPANY, et al.,

STIPULATION AND [PROPOSED] ORDER ON DISCOVERY OF
ELECTRONICALLY STORED INFORMATION
Pursuant to Fed. R. Civ. P. 16 and Fed. R. Civ. P. 26(f), the Court adopts and enters as an
Order the parties’ [Proposed] Stipulation and Order on Discovery of Electronically Stored
Information.

The procedures and protocols outlined herein govern the production of

electronically stored information (“ESI”) and paper documents that are produced in an electronic
format (the “ESI Protocol”) on or after the date of this Order. All disclosures and productions
made pursuant to the ESI Protocol are subject to the Stipulated Protective Order. The parties will
confer, if needed, for production formats for particular materials that are not addressed herein.
I.

General Provisions
A.

Counsel for Plaintiffs, E.I. DuPont de Nemours (“DuPont”), and The Chemours

Company FC, LLC (“Chemours”) have met and conferred regarding discovery of electronically
stored information and have reached agreement on certain of the issues discussed regarding such
discovery. The parties agree that the efficient and just resolution of this matter will be furthered
by mutual cooperation and transparency in responding to the parties’ requests for documents, and
the parties intend to promote, to the fullest extent possible, the resolution of disputes regarding the
discovery of ESI without Court intervention. The parties do not intend by entering this stipulation
to waive any privilege, work product protections, or other protections or objections in responding
to discovery.
B.

The Federal Rules of Civil Procedure will govern discovery, and no provision

herein alters any provision of the Federal Rules of Civil Procedure, local rules, or applicable law.
The terms of this Order shall be construed to ensure the cost-efficient and cost-effective exchange
of information consistent with the Federal Rules of Civil Procedure, local rules, and applicable
law.
II.

Definitions
A.

“Confidentiality Designation” means the legend affixed to Documents for

confidential and highly confidential discovery information as defined by, and subject to, the terms
of the parties’ Stipulated Protective Order.
B.

“Document” has the meaning contemplated in the Federal Rules of Civil Procedure

and, includes, without limitation, all ESI. The term “Document” includes Hard-Copy Documents,
Electronic Documents, and other ESI.
C.

“Electronic Document or Data” means Documents that are in electronic form at

the time of collection.
D.

“Electronically stored information” or “ESI,” means electronically stored

information, as that term is used in Federal Rule of Civil Procedure 34(a).
2

E.

“Hard Copy Document” means a document that is stored in paper form at the time

of collection.
F.

“Hash Value” is a number that uniquely identifies a file or specific data and that is

calculated using a standard mathematical hashing algorithm whose input comprises characteristics
of the respective file or data.
G.

“Load File” is an electronic file that can assist in loading an electronic production

set into a receiving party’s document review platform. For example, as described more fully
below, a Metadata Load File contains Metadata about the electronic production set, and an Image
Load File contains information to facilitate loading document images into the document review
platform.
H.

“Metadata” are information embedded in or associated with an Electronic

Document that are generated automatically by the operation of a computer or other information
technology system when the document is created, modified, transmitted, deleted, or otherwise
manipulated. The parties will not be required to manually populate any metadata fields.
I.

“Media” means an object or device, real or virtualized, including but not limited to

a disc, tape, computer or other device, on which data is or was stored.
J.

“Native Format” means the original format of ESI in which it was generated, used

and/or normally kept by the producing party in the usual course of its business and in its regularly
conducted activities. For example, the native format of an Excel workbook is a .xls or .xslx file.
K.

“OCR” is an abbreviation for “optical character recognition” and references a

process by which text contained within an Electronic Document in a non-searchable imaged format
is converted to a searchable text format.
L.

“Producing Party” means the Party producing documents during discovery.

3

M.

“Receiving Party” means the Party receiving documents during discovery.

N.

“Static Image(s)” means a representation of ESI produced by converting a Native

File into a standard image format capable of being viewed and printed on standard computer
systems. A Static Image may also be created by scanning a Hard-Copy Document. A Tagged
Image File Format (TIFF) image is an example of a Static Image.
III.

Form of Production
The parties will produce Documents in “a reasonably usable form.” Fed. R. Civ. P.

34(a)(1)(A). If a Party has previously processed or produced certain Documents in a form that is
different than that provided for herein, the Party is not required to produce the Documents in
accordance with this Protocol, provided that the form utilized is also “reasonably usable.” The
requesting party reserves the right to object to whether the form utilized is “reasonably usable.”
Notwithstanding the foregoing, the parties agree that the following forms of production are
“reasonably usable”: documents produced as TIFF images with load files utilizing Concordance
default delimiters, and files produced in native format pursuant to Section III.B with an
accompanying placeholder image / slip sheet bearing the Bates number and any confidentiality
designation required by the Parties’ protective order.
A.

Paper Documents/Hard Copy Scanned Images.
1.

Paper documents may be produced in hard-copy paper form. If a Party has

converted paper documents into an electronic form, including by scanning, then the Party will
produce those electronic scans in the form of TIFF images using best efforts in the unitization of
the document. The production will include a Metadata Load File and an Image Load file as
described more fully below in Section III.C. The Producing Party will not be required to manually
populate any of the fields in either Load File. The parties agree that to the extent the Producing
Party scanned hard copy documents prior to the entry of this Order, the Producing Party is not
4

required to re-scan those hard copy documents.
2.

To the extent practicable, paper documents and hard copy scanned images

shall be produced in the manner in which those documents were kept in the ordinary course of
business. Where a paper document or hard copy scanned image has identification spines, “postit” notes, or any other labels, the information on the label shall be scanned and produced to the
extent practicable. In scanning a paper document, if a document is more than one page, to the
extent reasonable, the unitization of the document and any attachments or affixed notes should be
maintained as it existed when collected by the producing party. The parties will utilize reasonable
best efforts to ensure that paper documents and/or hard copy scanned images in a single production
are produced in consecutive Bates number order.
B.

ESI
1.

Except as otherwise provided herein, the parties shall produce ESI in TIFF

format with a Metadata Load File, an Image Load File, and a corresponding text file. Word
processing files, including Microsoft Word files, will be produced as TIFF images in “last saved”
or “last modified” format and with tracked changes and comments showing in the TIFF image and
searchable in the extracted text, to the extent tracked changes and comments exist in the “last
saved” or “last modified” format. Presentation files, including PowerPoint, will also be produced
as TIFF images in “last saved” or “last modified” format with any speaker notes and hidden slides
showing and searchable in the extracted text, to the extent speaker notes and hidden slides exist in
“last saved” or “last modified” format. Audio files in non-standard formats should be produced in
MP3 or Native Format. Unless redacted, the following files shall be produced in Native Format
with extracted text and applicable Load Files: (a) electronic spreadsheets (e.g., Excel); (b) desktop
databases (e.g., Access); and (c) audio/video multimedia files. A producing party may also elect

5

to produce electronic presentations (e.g., PowerPoint) or word processing files (e.g. Word) in
Native Format with extracted text and applicable metadata fields set forth in Attachment A; these
files may otherwise be produced in TIFF format as provided for herein. The parties reserve the
right to request unredacted electronic presentations (e.g., PowerPoint) produced in TIFF format in
Native Format as necessary. If a document that otherwise would be produced in Native Format
requires redaction, such document may be produced as redacted in TIFF format or Native Format
in accordance with this Protocol and in compliance with Section III.B.2. If a party produces a
redacted document in TIFF format, a corresponding Native File version need not be produced, and
the TIFF version must display the above-referenced content such as tracked changes, comments,
speaker notes, hidden slides, and similar content. The redacted TIFF image will be OCR’d to
create a text file that shall be produced in lieu of extracted text.
2.

All TIFF-formatted documents will be produced in black-and-white as

single page Group IV, 300 DPI, when reasonably practicable. Image file names will be identical
to the corresponding Bates numbered images, with a “.tif” file extension. The requesting party
retains the right to request a TIFF image in a higher resolution or larger page size if necessary to
render the image legible or reasonably usable. If a party encounters a document where color is
reasonably necessary to comprehend the content, the producing party will cooperate to honor
reasonable and specific requests to re-produce that document in a color format. All images of
redacted documents that contain comments, deletions, revision marks (including the identity of the
person making the deletion or revision and the date and time thereof), speaker notes, or other userentered data that the source application can display to the user will be processed such that all data
is visible in the image, to the extent it exists in “last saved” or “last modified” format. For instances
in which only a portion of a document is redacted for privilege, the party claiming the privilege

6

will redact only the privileged portions and produce the remaining portions. The party may, at its
option, indicate the basis on the face of redaction. Documents that are partially redacted for
privilege and that indicate on their face the basis of the redaction on grounds of privilege need not
be placed on a privilege log if (a) the document’s metadata indicates the document has been
redacted for privilege and (b) the non-redacted portions provide sufficient context to identify and
evaluate the basis of the claim of privilege. The receiving party may request that the producing
party provide an explanation of the basis of claim of privilege for specific redacted documents and
such request shall not be unreasonably denied. The Producing Party’s production of a text file or
Metadata Load File containing information redacted from that Document shall not be deemed a
waiver of the privilege or other protection associated with that Document, and any metadata or
text file containing the text of redacted portions of a redacted Document or other privileged or
protected information shall be treated as protected information, consistent with the terms of
clawback provisions of the parties’ Stipulated Protective Order.
3.

All images must be assigned a Bates number that shall always: (1) be unique

across the entire document production, (2) maintain a constant length (zero/0-padded) across the
entire production, (3) contain no special characters or spaces, and (4) be sequential within a given
document. Bates numbers shall not obscure any portion of the original file. If Bates numbers are
skipped in a production range and not otherwise identified in a privilege log, then the producing
party will disclose the Bates numbers or ranges in a cover letter accompanying the production. A
single text file (.TXT) will be provided for each document produced. The text file name will be
the same as the Bates number of the first page of the respective document, with the extension “.txt”
suffixed. Electronic text must be extracted directly from the Native File unless the document
requires redaction, is originally an image file, is any other Native File that does not contain text to

7

extract (e.g., non-searchable PDFs), or where text cannot practicably be extracted. In these
instances, and in the case of imaged hard-copy documents, the TIFF image will be OCR’d to create
a text file that shall be produced in lieu of extracted text. Extracted text shall be provided in UTF8 format text and may include a Byte Order Mark. Extracted text shall include all available
comments, revisions, tracked changes, speaker’s notes, text from documents with comments or
tracked changes, as well as hidden worksheets, slides, columns, and rows. Text extracted from
emails shall include the following header information that would be visible if the email was viewed
in the e-mail application: (1) the individuals to whom the communication was directed (“To”), (2)
the author of the email communication (“From”), (3) who was copied and blind copied on such
email (“CC” and “BCC”), (4) the subject line of the email (“RE” or “Subject”), and (5) the date
and time of the email. The full path of the text file must be provided in the Metadata Load File.
4.

The parties will disclose the time zone used for field dates and times.

5.

OLE embedded objects (embedded MS Office files, etc.) shall be extracted

as separate files and treated as attachments to the parent document where practicable. Images
embedded in emails shall not be produced as attachments unless they are responsive to a discovery
request served upon the producing party, e.g., logos and junk files embedded in emails do not need
to be produced as attachments.
6.

Documents that contain languages other than English, in whole or in part,

shall be produced in the original language(s).
7.

OCR software should be set to the highest quality setting during processing.

Settings such as “auto-skewing” and “auto-rotation” should be turned on during the OCR process.
A Bates-stamped placeholder TIFF, bearing a legend indicating that the document was produced
natively shall be provided for ESI produced in native format, unless the document is also produced

8

in TIFF format. These placeholders will be Bates numbered in the same way as any other TIFF,
and the Bates number of that single page shall be used as the BegBates and EndBates of the
associated document, and the “PGCOUNT” field in the Metadata Load File for the placeholder
shall contain “1.”
8.

The parties will meet and confer to address the production and production

format of any responsive data contained in a database or other structured or aggregated data source
under the possession, custody, or control of the parties. The parties anticipate that certain
productions of structured data may require the parties to first exchange information about the
pertinent database, including to discuss the efficient retrieval and production of data contained
therein.
9.

Parent-child relationships (the association between an attachment and its

parent document or between embedded documents and their parent) shall be preserved. A
document and all other documents in its attachment range, emails with attachments, and files with
extracted embedded OLE documents all constitute family groups.

If any member of a family

group is produced, all responsive members of that group must be also be produced. If a party does
not produce a member of a family group on the grounds that it is non-responsive, then the party
will include a slip-sheet stating that the attachment is withheld as non-responsive, unless the
attachment is a non-responsive OLE embedded object as set forth in Section III.B.5 above. The
parties may meet and confer to discuss requests to produce an attachment that has been slip-sheeted
as non-responsive.
10.

A Producing Party will take reasonable steps to unencrypt any discoverable

ESI that exists in encrypted form (e.g., password-protected) and that can be reasonably
unencrypted. A Producing Party will not be required to guess passwords or otherwise produce

9

documents that are not reasonably accessible.
11.

The parties will use best efforts to produce responsive social media in

accordance with this Order, but where it is not reasonably practicable to produce responsive social
media in the manner set forth in this Order, the parties shall meet and confer to discuss the most
practicable manner of production. In connection with such discussions, the Producing Party shall
produce a test production when requested by a receiving party. In general, even where social
media cannot be produced in accordance with this Order, a Producing Party must produce
responsive social media in a reasonably usable form.
12.

Absent a specific showing of need, the following categories of ESI are not

discoverable in this case: deleted, slack, fragmented, or unallocated data on media; random access
memory (RAM) or other ephemeral data; and online access data such as temporary internet files,
history, cache, cookies, etc. Federal Rule of Civil Procedure 37(e) governs the loss of
electronically stored information that should have been preserved in the anticipation or conduct of
litigation because a party failed to take reasonable steps to preserve it and it cannot be restored or
replaced through additional discovery.

If a party demonstrates a specific need for information

encompassed by this section and to the extent such information exists, the parties shall meet and
confer on whether such data should be produced, preserved on a forward-looking basis, and/or
whether cost-shifting is appropriate. However, prior to a showing of a specific need and an
agreement among the parties on the need or Court order accepting the need, there shall be no
obligation to preserve such information.
13.

Common system and program files as defined by the NIST library need not

be preserved, collected, processed, reviewed, or produced.
C.

Load Files.

There will be two Load/Unitization files accompanying all

10

productions. One will be the Image Load File and the other will be the Metadata Load File. The
specifics of these files are set forth below. To the extent a Producing Party departs from the
specifics of these files, it shall disclose such deviation to the receiving party. The parties will use
consistent load file parameters throughout their respective productions.
1.

Image Load File
(a) Every Document referenced in a production Image Load File
shall have all corresponding images, text, and data logically grouped together
in a directory structure with a common key to properly load the data.
(b) Documents shall be produced in only one Image Load File
throughout the productions, unless that document is noted as being a
replacement document in the Replacement field of the corresponding Metadata
Load File.
(c) If produced on media, the name of the Image Load File shall
mirror the name of the delivery volume or the production date, and should have
an .lfp, .opt or .dii extension (e.g., ABC001.lfp). If named by delivery volume,
the volume names shall be consecutive (i.e., ABC001, ABC002, et seq.). *If a
.dii file is produced, the accompanying Metadata Load File shall be separate
from the .dii file and not contained within the .dii file. The Image Load File
shall contain one row per TIFF image.
(d) Every image in the delivery volume shall be referenced by Bates
number in the Image Load File.
(e) The image key shall be named the same as the Bates number of

11

the page. If produced on media, load files shall not span across media (e.g.,
CDs, DVDs, hard drives, etc.). In other words, a separate volume shall be
created for each piece of media delivered.
2.

Metadata Load File
(a)

The metadata load file shall use Concordance default delimiters,

or if a party is using different delimiters then the delimiters will be disclosed.
(b)

Data for a document shall be produced in only one data load file

throughout the productions, unless that document is noted as being a replacement
document.
(c)

The first record shall contain the field names as columns in the

order of the data set forth in Attachment A, infra. Metadata fields that are not
applicable to a document shall be filled with a NULL value or left blank along with
fields that were not able to be obtained due to a processing error or corrupt file.
(d)

Date fields shall be produced in “mm/dd/yyyy hh:mm:ss AM”

or “M/D/YYYY hh:mm:ss AM” format.
(e)

A carriage-return line-feed shall be used to indicate the start of

the next record.
(f)

Load Files shall not span across media (e.g., CDs, DVDs, hard

drives, etc.). In other words, a separate volume shall be created for each piece of
media delivered.
(g)

The name of the Metadata Load File shall mirror the name of the

delivery volume or production date, and shall have a .dat, .csv or .txt extension (i.e.,
ABC001.dat).

12

(h)

The volume names shall be consecutive for each produced

source (i.e., ABC001, ABC002, et seq.).
D.

De-duplication. “Duplicate ESI” means, for a stand-alone document, that one

document is the exact duplicate of another stand-alone document, or for an e-mail family, that one
e-mail family is the exact duplicate of another e-mail family based on the stand-alone files’ or the
e-mail families’ identical MD5 or SHA-1 Hash Values. The producing party need only produce a
single copy of responsive Duplicate ESI. However, no document that is a member of an e-mail
family or is the parent or an attachment of a produced document may individually be withheld
from production as a duplicate, and no stand-alone document may be withheld as a duplicate based
on the presence of that stand-alone document within an e-mail family. If a producing party deduplicates documents across its various productions, then the producing party shall provide the
names of all original file locations of the duplicates of a particular document in the relevant load
file.

A Producing Party employing a deduplication process certifies that its process is

commercially acceptable. The Producing Party agrees that the presence of a custodian’s name
contained in “all custodians” or “other custodians” in the metadata for a particular document is
evidence that a duplicate of the document was located in that custodian’s file.
E.

E-mail Threading.

The Parties may use industry standard “email thread

suppression.” As used in this Protocol, email thread suppression means reducing duplicative
production of email threads by producing only the most inclusive email containing the thread of
emails, as well as all attachments within the thread. Duplicative emails suppressed under this
paragraph need not be reflected on the Party’s privilege log. If the most inclusive email in a thread
is redacted in its entirety as privileged, but earlier emails in the thread are responsive and not
privileged, then the unredacted portion of the thread must be produced.

13

F.

Proprietary Software. To the extent that relevant ESI cannot be rendered or

reviewed without the use of proprietary software that is not commercially available, the parties
shall meet and confer to discuss and attempt to reach a mutually agreeable resolution.
G.

Redactions. Except as provided in paragraph 13 above regarding non-responsive

attachments, no redactions for relevance may be made within a produced document or ESI item.
For redacted items that were originally ESI, all applicable metadata fields will be provided and
will include all non-redacted data. Redacted documents need not be logged as long as the Metadata
Load File indicates the document is redacted for privilege and (a) for e-mails, the information in
the Metadata Load File for the document is not redacted, and (b) for non-e-mail documents, the
redaction is noted on the face of the document. The receiving party may request that the producing
party provide an explanation of the basis of claim of privilege for specific redacted documents and
such request shall not be unreasonably denied.
H.

Production Media. The producing party will use the appropriate electronic media

(CD, DVD, flash/thumb drive or hard drive) for its ESI production, and will cooperate in good
faith to use media with the appropriate storage capacity to minimize associated overhead. A party
who receives a production on a hard drive must return the drive to the producing party after
transferring the data. Alternatively, a party may produce via a secure FTP or Sharefile link,
provided that, after making such a production, the producing party honors timely and reasonable
requests for a copy provided on physical media if the size of the production imposed an
unreasonable burden on the receiving party to download the files.

If a party produces a

replacement production, the party will cross-reference the original production and identify the
replacement as being a replacement.
I.

Production Problems. If a receiving party believes that a document, as produced,

14

does not comply with the production format requirements herein, the receiving party may notify
the producing party of the alleged non-compliance, and as necessary, the parties will promptly
meet and confer regarding a reasonable resolution of any such production-format issue. If the
party identifying the issue can provide samples (i.e. documents’ Bates numbers) of an issue, it
should do so.
IV.

ESI Procedures
A.

Cooperation. The parties shall conduct discovery in a cooperative manner and

shall meet and confer in good faith on issues as may arise during the course of discovery.
B.

Search Methodologies. Search terms may be used to identify files for review and

production. To the extent a producing party wishes to use search terms, technology-assisted
review, or other electronic search methodologies to cull documents from review and production,
the parties shall meet and confer and attempt in good faith to reach agreement regarding the search
methodology, including the identities of custodians from whom ESI will be collected and searched.
V.

General Provisions.
A.

The parties agree to exchange search terms to the extent they intend to apply them

to their respective ESI and agree to meet and confer over the use of search terms in an effort to
reach agreement on them, including whether the use of certain hit reports and/or sampling would
be reasonable and appropriate. If a party uses predictive coding, then before doing so, that party
will first disclose its intended use and meet and confer with the parties to reach agreement on the
method that will be applied.
B.

This Protocol does not address, limit, or determine the authenticity, admissibility,

or relevance of any Document.
C.

Nothing in this Protocol shall be interpreted to limit a Producing Party’s right to

15

conduct a review of Documents, including metadata, for relevance, responsiveness, or segregation
of privileged or protected information before production.
D.

Any practice or procedure set forth herein may be varied by agreement of the

parties, and such variance first will be confirmed in writing, where such variance is deemed
appropriate to facilitate the timely and economical exchange of electronic data or other covered
discovery materials.
E.

Should any party subsequently determine in good faith that it cannot proceed as

required by this Order or that the Order requires modification, the parties will meet and confer to
resolve any dispute before seeking Court intervention.

DATED:

October 8, 2019

/s/ Joseph A. Ponzi
Joseph A. Ponzi
N.C. Bar No. 36999
George W. House
N.C. Bar No. 7426
William P. H. Cary
N.C. Bar No. 7651
V. Randall Tinsley
N.C. Bar No. 14429
BROOKS, PIERCE, McLENDON,
HUMPHREY & LEONARD, LLP
Post Office Box 26000
Greensboro, NC 27420-6000
Telephone: [phone]
Facsimile: [phone]
[e-mail]
[e-mail]
[e-mail]
[e-mail]

By: /s/ Kenneth J. Reilly
John K. Sherk III
Tammy B. Webb
SHOOK, HARDY & BACON, LLP
One Montgomery Tower, Suite 2600
San Francisco, CA 94104
Telephone: [phone]
Facsimile: 415-391-0281
[e-mail]
[e-mail]
Kenneth J. Reilly
SHOOK, HARDY & BACON, LLP
Citigroup Center, Suite 3200
201 South Biscayne Boulevard
Miami, FL 33131-4332
Telephone: [phone]
Facsimile: 305-358-7470
[e-mail]

Attorneys for Plaintiff Cape Fear Public
Utility Authority

16

Jonathan D. Sasser
Stephen D. Feldman
ELLIS & WINTERS, LLP
P.O. Box 33550

/s/ M. Cristina Sanchez___________
Scott Summy
Cary L. McDougal
Stephen C. Johnston
M. Cristina Sanchez
Brett D. Land
BARON & BUDD, P.C.
3102 Oak Lawn Avenue, Suite 1100
Dallas, Texas 75219-4281
Telephone: [phone]
Fax: [phone]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]

Raleigh, NC 27636
Telephone: [phone]
Facsimile: 919-865-7010
[e-mail]
[e-mail]
Attorneys for Defendants

J. Harold Seagle
SEAGLE LAW
P.O. Box 15307
Asheville, N.C. 28813
Telephone: [phone]
[e-mail]
Attorneys for Plaintiffs Brunswick County,
Town of Wrightsville Beach, and Lower
Cape Fear Sewer & Water Authority

17

IT IS SO ORDERED.

Dated: ______________, 2019
Dated: October 11, 2019
______________________________________
___________________________________
Robert T. Numbers, II
United Hon. James C. Dever III
States Magistrate Judge
U.S. District Judge

18

Attachment A
Absent a showing of good cause, a Party is only required to produce the metadata
provided in the following fields applicable for the given produced document type, and in any
event only insofar as such metadata is readily available, responsive, and not subject to the
attorney-client privilege, work-product doctrine, or any other applicable privilege.

Field

Definition

Hard-Copy
Scanned Image

E-Document
E-mail

CUSTODIAN

Name of person or other
data source (non-human)
from where documents/files
are produced. Where
redundant names occur,
individuals should be
distinguished by an initial
which is kept constant
throughout productions
(e.g., Smith, John A. and
Smith, John B.)

Yes

Both

BEGBATES

Beginning Bates Number

Yes

Both

ENDBATES

End Bates Number

Yes

Both

PGCOUNT

Number of pages in the
document

No

Both

FILESIZE

File Size

No

Both

APPLICAT

Commonly associated
application for the
specified file type

No

Both

FILENAME

File name at collection

No

E-Document

NATIVEFILELINK

For documents provided in
native format

No

E-Document

1
6888576v1 02034/015780

TEXTPATH

File path for OCR or
Extracted Text files

Yes

Both

MSGID

Email system identifier
assigned by the host email
system. This value is
extracted from parent
message during processing

No

E-mail

Folder

Folder location of the email within the PST/OST

No

E-mail

FROM

Sender

No

E-mail

TO

Recipient

No

E-mail

CC

Additional Recipients

No

E-mail

BCC

Blind Additional Recipients

No

E-mail

SUBJECT

Subject line of e-mail

No

E-mail

ATTACHBATES

Bates number from the first
page of each attachment

No

E-mail

BEGATTACH

Bates number of the first
page of the parent e-mail

Yes

E-mail

ENDATTACH

Bates number of the last
page of the last attachment

Yes

E-mail

ATTACHCOUNT

Number of attachments to
an e-mail

No

E-mail

ATTACHNAMES

Names of each individual
Attachment, separated by
semi-colons

No

E-mail

2
6888576v1 02034/015780

DATESENT
(mm/dd/yyyy
hh:mm:ss AM)

Date Sent

No

E-mail

DATERCVD
(mm/dd/yyyy
hh:mm:ss AM)

Date Received

No

E-mail

File Description

System generated item
description, e.g., Word,
email, calendar item,
contact, note, task

No

E-Document

HASHVALUE

MD5 or SHA-1 hash value

No

Both

TITLE

Title from within the
document

No

E-Document

AUTHOR

Creator of a document

No

E-Document

DATECRTD
(mm/dd/yyyy
hh:mm:ss AM)

Creation Date

No

E-Document

FSDATECRTD

File system date created

No

E-Document

LAST MODIFIED BY

Last user who modified a
document

No

E-Document

LASTMODD
(mm/dd/yyyy
hh:mm:ss AM)

Last Modified Date

No

E-Document

FSLASTMODD

File system date
modified

No

E-Document

3
6888576v1 02034/015780

Importance

High Importance set for
email

No

E-mail

Confidentiality

Confidentiality level of
document in accordance
with the Stipulated
Protective Order

Yes

Both

Replacement

Insert the word
“Replacement” if the image
is a replacement for a
previously produced image;
otherwise blank

Yes

Yes

Redaction

Insert the word “Redacted”
if the document contains
any redaction; otherwise
blank

Yes

Yes

Redaction Reason

The reasons for redaction

Yes

Yes

The following fields should be included if de-duplication is used across
custodian
OtherCustodians

Custodians of unproduced
duplicate documents.
Multiple values separated
by semi-colons.

4
6888576v1 02034/015780

No

Both