Sample Electronic Discovery Document Production Request

According to Rule 34 of the FRCP, a party in litigation may serve on any other party a request for production of relevant documents. This request must specify with reasonable particularity each item or category of new items to be inspected. The request may also specify the form in which ESI is to be produced. Although not technically required in the Federal Rules, the form of production is a crucial negotiating point to ensure that production load file and data from the opposing party can be processed and utilized effectively in  your firm's eDiscovery tool. We often see "bad" data come in from the opposing party or a third party. If this occurs, you may need to pay for service hours of consultants and experts to fix the load files or identify the specific documents that are causing problems. In order to help you get ahead on potential issues with opposing party data, this blog provides a sample request which defines the form of production. Aside from this, you will also need to keep in mind other requirements in rule 34 and rule 26 which describe your requirements to discuss issues relating to: specificity, the eDiscovery process, timing, logistics regarding how the production will be delivered and how it can be accessed. Most importantly, we recommend working closely with the opposing party to identify these issues as early as possible. If you have any specific questions, consult your eDiscovery vendor (or leave us a message)!

Standard Load File

Digital WarRoom software with no customizations or extra work on your part can produce sets of standard load files for use by common and current ediscovery platforms and more than fulfill your obligations in reasonable production.

Data is generally accommodated by information in the 'DAT' or meta-data load file that includes both text links and native links as the most common practice for many years.     Nearly all platforms also provide, and infer upon receipt, that matched set of plain text OCR files exist with identical bates number file names as image files, and often will properly address without a load file.

Folks often call opt files ‘opticon’ and DAT files ‘concordance’ load files. While not precise, it is the common vernacular, and our load files are formatted to the standard / common spec used in OPT, LFP, and DAT. Your DWR DAT files have what some folks call the 'Concordance' delimiter or the ''Quote Character" ... it may not be super obvious visually, but I am pasting below the header row of a DAT file out of DWR with the field separator.

þBEG BATESþþEND BATESþþBEGATTACHþþENDATTACHþþBATES PREFIXþþBCCþþCCþþDATEþþDATE_TIMEþþFROMþþTHREAD GROUPþþTITLEþþTOþþSIZEþþCUSTODIANþþNATIVE_FILEþþOCR_FILEþ


Please do note that DWR - and most current generation platforms - will provide standard load files as follows:

CSV
DAT
OPT
LFP

Within DWR, You can use the field chooser to select which meta-data columns to include, we general suggest the Keep It Simple method.

This article includes an example ESI agreement that can be freely shared and might have some useful information. Keeping in mind that all parties have the right to negotiate, not make discovery demands - sample available below. All of these negatiations are subject to reasonableness doctrines.

Common Metadata And ESI in Electronic Discovery Requests

Generally speaking - and codified in the FRCP which are mostly mirrored in states - where the original documents were ESI (Electronically Stored Information - emails, attachments, office documents, etc.), parties don't have much burden in providing:

BEG BATES
END BATES
BEGATTACH
ENDATTACH
CUSTODIAN
CREATED
MODIFIED
TITLE (FILENAME OR EMAIL SUBJECT AS APPROPRIATE) 
EXT (FILE EXTENSION)
MD5 (HASH VALUE)
PATH (FILE PATH OR LOCATION ON DISK OR EMAIL FOLDERS WHERE ITEM LOCATED)
SIZE

AUTHOR (application meta-data - often blank or junk)
TO
FROM
BCC
CC
RECEIVED
SENT
THREAD GROUP


The following are not ‘meta-data’, but used by programs to support ingestion

NATIVELINK  (link to any included native files where slip-sheets have been delivered)
OCRPATH   (link to OCR / extracted text files for associated images)


For ease of use, most parties use a single field for the dates ... computers store the date and time as a single attribute in standard format.  Splitting them into separate date and time fields is counterproductive.

I also tend to suggest that folks include a 'SORT DATE' or 'DATE' field ... this is a unified date for an email and it's attachments that makes it easier for attorneys to sort by date (Chronologically order a review), yet still keep emails and attachments together.   The created / modified / sent / received save different (and valuable) information.

There are many more attributes available in application meta data (think MS Word, PowerPoint, Excel for example) like 'last printed', 'revisions', 'doc title', 'tags', and such, but those sort of items tend to be of less value for most cases. There are also many other elements of meta-data to consider, but rather than take a long tangent, if the above are in line with what ensure level playing field, that's a good starting place.

Sample ESI Agreement

In this example, electronic documents should be provided to the following specifications.  

1) Single Page TIFs

Except as discussed below in section 6, all documents existing in electronic format shall be produced in a Group IV TIF compression, single-page, black and white format at a resolution of at least 300 dpi.

2) Document Level Text Files

For each document, a text file shall be provided along with the TIF images.  The text of native files shall be extracted directly from native files, one text file per document.  Each text file will be named with the first production number of the images which comprise the original document followed by the extension TXT.   Documents for which no text is extracted will be OCR scanned using best reasonable efforts by the parties and such text provided as separate text files, one text file per document.

3) Unique ID Numbering

Each TIF file shall be named with a unique production number followed by the extension “.TIF.” In addition, each text file (whether derived from direct extracted or from OCR) shall be named with the unique production number of the corresponding TIF image, followed by the extension “.TXT.”  Each media produced shall be uniquely named with a sequential number that includes an identifier unique to each party.  The parties will cooperate to ensure that the logistics of production are efficient and economical, including production media, and naming conventions and procedures for directories and subdirectories.

4) Load Files

Both electronic documents and hardcopy sourced documents will be provided with 4 load files:

1) an IPRO delimited file;

2) a Concordance delimited file or Concordance database;

3) an Opticon delimited file

4) a metadata load file with the fields noted in paragraph

Every electronic document must be referenced in a load file.

Metadata and any objective coding provided should be provided in the following format:

• Metadata should be pipe (|) delimited;
• String values within the metadata file should be enclosed with carats (^};
• The first line should contain metadata headers and below the first line there should be exactly one line for each document; and
• Each row of metadata must contain the same amount of files as the header row.

5) Metadata Fields

The parties shall identify and produce metadata fields, as set forth below, for all electronic documents.  Specifically, in addition to the text file associated with the TIF images a separate load file with accompanying metadata will be provided.

Metadata load files shall also be provided for certain hard copy and scanned documents where manual coding has been conducted.  If manual coding has been conducted and the fields noted below are available they shall be provided but there is no obligation to create metadata that does not exist.  For hard copy sourced documents, the parties are obliged to provide custodian and location information to note the source of the material.

Metadata fields

1. Title (or subject);
2. Date created;
3. Last date modified;
4. Created by;
5. Edited (modified) by;
6. For email: sent from, to, cc, bcc or recipients;
7. Starting production number;
8. Ending production number;
9. Starting production number of attachment(s);
10. Ending production number of attachment(s);
11. Custodian;
12. Document type or file extension; and
13. Original File path.

Parent-Child Relationship (the association between an attachment and its parent document) should be indicated in the metadata.  All parties will produce document(s) attached to an email sequentially after the parent email.

6) Native Format

After reviewing the TIF production, parties can, upon demonstrating a particularized need for production, request a TIF image at a higher resolution or color depth; color or other high quality hard copy, or native format of any documents by identifying such documents by production number range.  Should the parties be unable to agree on the production request of a particular document under this paragraph, the requesting party may move to compel such production and the producing party shall have the burden to establish that the burden of producing the document substantially outweighs its benefit.

Should single-image TIF files from Excel spreadsheets (or other spreadsheets or databases) reproduce in an unformatted/unwieldy way, the receiving party can request and upon showing particularized need the producing party will provide native Excel files with locked cells and no metadata (or other spreadsheet files or database files in like manner).  

Certain multi-media files, audio and visual presentations, and other files that cannot be rendered as static TIF images will be produced in native electronic format by the parties.  In such case, a placeholder slip-sheet TIF image indicating that the original electronic file could not be converted to TIF will be included in the appropriate sequence with the production number indicated.  The native file will be provided concurrently with the placeholder slip-sheeted image.  The file name will have the production number appended to the original file name with the original native file extension.

Source code produced through discovery will be pursuant to the terms of the protective order.

7) Production Media

All discoverable electronic information shall initially be produced in electronic image format in the manner provided above, on a hard drive, CD, DVD, or other mutually agreeable format on the most reasonable capacity media for each production set in capacity to ensure efficient handling by all parties.   One USB hard drive is preferable to 5 DVDs, for example.

Because of the potential for a large number of documents to be produced, it may not be possible to review all images immediately upon production.  The parties agree that no rights are waived should an issue not be immediately identified with the production media or the document images. 

If you found this article interesting, be sure to subscribe you and your team to our monthly blog distribution email. This email list is solely for blog distribution purposes and we promise to only send one email per month. To subscribe, simply scroll down and fill out the "Subscribe" form below the comment box.