PLEASE COMMENT
Lead author: Julie Brown (Vorys, Sater, Seymour and Pease LLP)
Updated July 8, 2010
The purpose of this document is to outline standards for production of electronically stored information in discovery. The intent is for these standards to be easily communicated by attorneys at a meet and confer by referring to the category of production. The following definitions are provided regarding the forms of production (See the EDRM Production Guide for further clarification on the forms of production, http://edrm.net/resources/guides/edrm-framework-guides/production):
- Native Format – Files are produced in the format in which they were originally created (Example: .docx produced in .docx; .pdf produced in .pdf, etc.)
- Near-Native Format – Files are extracted or converted into another searchable format (Example: e-mails produced in .htm, .mht, or .rtf; Databases produced in .txt or .csv format)
- Image (Near Paper) Format – Electronic files are converted to image format or paper is scanned to image format
- Paper – Electronic files are printed to paper or paper files remain in paper format
The categories of production identified below include A1, A2, B1, B2, C1, C2, D and E. The descriptions of the standards are followed by a Quick Guide to Components of Productions A-D, a chart containing the Characteristics of Productions A-D and a chart containing the required metadata and other information fields. In addition to agreeing to one of these standards, the requesting party should tell the producing party which review tool they will be using. This information is needed to properly identify the components and formats required to successfully load the information into a review tool.
A. Native/Near-Native Production
E-mail, databases and proprietary files are produced in a near native format. Attachments and loose files are produced in native format. Only files requiring redaction are tiffed.
- Includes searchable text for redacted files:
- Each native /near-native file name matches the DocID. (I.e. DocID = ABC0000123; Filename = ABC0000123.doc for MS Word document.)
- Each searchable native/near native file has an extracted text file in .txt format named with the DocID of the corresponding file. Each non-searchable file containing text has a multipage OCR text file named with the DocID of the corresponding file. (I.e. DocID = ABC0000123; Filename = ABC0000123.txt.)
- Each file requiring redaction has group IV single page tifs. Each file requiring redaction has a unique bates number applied to images matching the DocID or Bates number. The same number may be applied to each page within a document or the numbers can increment by page.
- OCR for redacted files in multipage .txt format. Each file named the same as the DocID/Bates number of the corresponding document. (I.e. Image Filename = ABC0000123.tif; OCR Filename = ABC0000123.txt.)
- Load file(s) for native/near-native, images, extracted text and OCR files in EDRM xml or common format such as that required by Concordance or Summation.
- Data file including, at a minimum, the standard EDRM extracted metadata and other information fields to the extent they exist (see chart below). This data may be included in load file or produced as a separate text delimited file.
- Does not include searchable text for redacted files:
- Each native /near-native file name matches the DocID. (I.e. DocID = ABC0000123; Filename = ABC0000123.doc for MS Word document.)
- Each searchable native/near native file has an extracted text file in .txt format named with the DocID of the corresponding file. Each non-searchable file containing text has a multipage OCR text file named with the DocID of the corresponding file. (I.e. DocID = ABC0000123; Filename = ABC0000123.txt.)
- Each file requiring redaction has group IV single page tifs. Each file requiring redaction has a unique bates number applied to images matching the DocID or Bates number. The same number may be applied to each page within a document or the numbers can increment by page.
- Load file(s) for native/near-native, images, extracted text and OCR files in EDRM xml or common format such as that required by Concordance or Summation.
- Data file including, at a minimum, the standard EDRM extracted metadata and other information fields to the extent they exist (see chart below). This data may be included in load file or produced as a separate text delimited file.
B. Image (Near-Paper)/Native/Near-Native Production
Most files are converted to image format (tif, pdf, etc.) with the exception of files like MS Excel that are not usable in image format.
- Includes searchable text for redacted files:
- Most Native/near native files are converted to group IV single page tif. Each file has a unique bates number applied to images matching the DocID or Bates number. The same number may be applied to each page within a document or the numbers can increment by page.
- Each searchable native/near native file has an extracted text file in .txt format named with the DocID of the corresponding file. Each non-searchable file containing text has a multipage OCR text file named with the DocID of the corresponding file. (I.e. DocID = ABC0000123; Filename = ABC0000123.txt.)
- Spreadsheets and files that are not usable in .tif format are produced in native or near-native format and named the same as the Doc ID. (I.e. DocID = ABC0000123; Filename = ABC0000123.xls for MS Excel document.)
- OCR for redacted files in multipage .txt format. Each file named the same as the DocID/Bates number of the corresponding document. (I.e. Image Filename = ABC0000123.tif; OCR Filename = ABC0000123.txt.)
- Load file(s) for native/near-native, images, extracted text and OCR files in EDRM xml or common format such as that required by Concordance or Summation.
- Data file including, at a minimum, the standard EDRM extracted metadata and other information fields to the extent they exist (see chart below). This data may be included in load file or produced as a separate text delimited file.
- Does not include searchable text for redacted files:
- Most Native/near native files are converted to group IV single page tif. Each file has a unique bates number applied to images matching the DocID or Bates number. The same number may be applied to each page within a document or the numbers can increment by page.
- Each searchable native/near native file has an extracted text file in .txt format named with the DocID of the corresponding file. Each non-searchable file containing text has a multipage OCR text file named with the DocID of the corresponding file. (I.e. DocID = ABC0000123; Filename = ABC0000123.txt.)
- Spreadsheets and files that are not usable in .tif format will be produced in native or near-native format and named the same as the Doc ID. (I.e. DocID = ABC0000123; Filename = ABC0000123.doc for MS Word document.)
- Load file(s) for native/near-native, images, extracted text and OCR files in EDRM xml or common format such as that required by Concordance or Summation.
- Data file including, at a minimum, the standard EDRM extracted metadata and other information fields to the extent they exist (see chart below). This data may be included in load file or produced as a separate text delimited file.
C. Image Production
All files are converted to image format (tif, pdf, etc.).
- Includes searchable text for redacted files:
- All Native/near native files are converted to group IV single page tif. Each file has a unique bates number applied to images matching the DocID or Bates number. The same number may be applied to each page within a document or the numbers can increment by page.
- All images are black & white except for those that require color for interpretation. Color images are produced in .jpg format unless otherwise agreed.
- Container files such as .zip or .rar may be converted to .tif format with a table of contents or referenced in the “folder” field containing the path to the original native file as it existed at the time of collection.
- Each searchable native/near native file has an extracted text file in .txt format named with the DocID of the corresponding file. Each non-searchable file containing text has a multipage OCR text file named with the DocID of the corresponding file. (I.e. DocID = ABC0000123; Filename = ABC0000123.txt.)
- OCR for redacted files in multipage .txt format. Each file named the same as the DocID/Bates number of the corresponding document. (I.e. Image Filename = ABC0000123.tif; OCR Filename = ABC0000123.txt.)
- Load file(s) for image files, extracted text and OCR in EDRM xml or common format such as that required by Concordance or Summation.
- Data file including, at a minimum, the standard EDRM extracted metadata and other information fields to the extent they exist (see chart below). This data may be included in load file or produced as a separate text delimited file.
- Does not include searchable text for redacted files:
- All Native/near native files are converted to group IV single page tif. Each file has a unique bates number applied to images matching the DocID or Bates number. The same number may be applied to each page within a document or the numbers can increment by page.
- Each searchable native/near native file has an extracted text file in .txt format named with the DocID of the corresponding file. Each non-searchable file containing text has a multipage OCR text file named with the DocID of the corresponding file. (I.e. DocID = ABC0000123; Filename = ABC0000123.txt.)
- Load file(s) for image files, extracted text and OCR in EDRM xml or common format such as that required by Concordance or Summation.
- Data file including, at a minimum, the standard EDRM extracted metadata and other information fields to the extent they exist (see chart below). This data may be included in load file or produced as a separate text delimited file.
D. Custom
- Images, Load File, Data file and no searchable text
- Images only
- Paper
- Other
E. On-line Production
Files presented for production via online review tool. Formats, fields, loads and exports to be negotiated on a case by case basis.
Quick Guide to Components of Productions A-D
| Production | Native | Near Native | Images | Extracted Text | OCR Text | Searchable Text for Redacted Files | Load File | Data File |
|---|---|---|---|---|---|---|---|---|
| A1 | x | x | x | x | x | x | x | x |
| A2 | x | x | x | x | x | x | x | |
| B1 | x | x | x | x | x | x | x | x |
| B2 | x | x | x | x | x | x | x | |
| C1 | x | x | x | x | x | x | ||
| C2 | x | x | x | x | x | |||
| D1 | x | x | x | |||||
| D2 | x |
Characteristics of Productions A-D
| Characteristics | A1 | A2 | B1 | B2 | C1 | C2 | D1 | D2 | D3 |
|---|---|---|---|---|---|---|---|---|---|
| Increase costs for image conversion | x | x | x | x | x | x | x | ||
| Increase turn around time for image conversion of majority of data set | x | x | x | x | x | x | x | ||
| Increase cost and turn around time for OCRing redacted files | x | x | x | ||||||
| Files are not searchable | x | x | x | ||||||
| Files such as spreadsheets and small databases are not in a format conducive for review | x | x | x | x | x | ||||
| Cannot individually number or endorse pages for document control | x | x | x | x | |||||
| Cannot brand pages with confidentiality endorsements | x | x | x | x | |||||
| Risk of accidental alteration is greater than with image format | x | x | x | x | |||||
| Metadata may be hidden and not fully reviewed prior to production | x | x | x | x | |||||
| May require native application or provision of client’s proprietary software to open files | x | x | x | x | |||||
| Cost of conversion and printing | x | ||||||||
| No link back to native file | x | x | |||||||
| No database or text for searching | x | x |
Metadata and Other Information Fields
| Fields for email (Not All Inclusive) | Description |
|---|---|
| ATTACHMENTIDS | Docids of attachment(s) to email/edoc |
| BATES RANGE | Begin and end bates number of a document if it differs from DocID; this can be provided in one bates range field or 2 separate fields for the beginning and ending number |
| BCC | Names of persons blind copied on an email |
| CC | Names of persons copied on an email |
| CUSTODIAN | Name of person from whom the file was obtained |
| DATERECEIVED | Date email was received |
| DATESENT | Date email was sent |
| DOCEXT | Extension of native document |
| DOCID | Unique number assigned to each file or first page |
| DOCLINK | Full relative path to the current location of the native or near-native document used to link metadata to native or near native file |
| FILENAME | Name of the original native file as it existed at the time of collection |
| FOLDER | File path/folder structure for the original native file as it existed at the time of collection |
| FROM | Name of person sending an email |
| HASH | Identifying value of an electronic record – used for deduplication and authentication; hash value is typically MD5 or SHA1 |
| PARENTID | DocId of the parent document |
| RCRDTYPE | Indicates document type, i.e., email; attachment; edoc |
| SUBJECT | Subject line of an email |
| TIMERECEIVED | Time email was received in user’s mailbox |
| TIMESENT | Time email was sent |
| TO | Name(s) of person(s) receiving email |
| Fields for edocs & Attachments (Not All Inclusive) | Description |
|---|---|
| ATTACHMENTIDS | DocIds of attachment(s) to email/edoc |
| AUTHORS | Name of person creating document |
| BATES RANGE | Begin and end bates number of a document if it differs from DocID; this can be provided in one bates range field or 2 separate fields for the beginning and ending number |
| CUSTODIAN | Name of person from whom the file was obtained |
| DATECREATED | Date document was created |
| DATESAVED | Date document was last saved |
| DOCEXT | Extension of native document |
| DOCID | Unique number assigned to each file or first page |
| DOCLINK | Full relative path to the current location of the native or near-native document used to link metadata to native or near native file |
| DOCTITLE | Title given to native file |
| FILENAME | Name of the original native file as it existed at the time of collection |
| FOLDER | File path/folder structure for the original native file as it existed at the time of collection |
| HASH | Identifying value of an electronic record – used for deduplication and authentication; hash value is typically MD5 or SHA1 |
| PARENTID | DocId of the parent document |
| RCRDTYPE | Indicates document type, i.e., email; attachment; email attachment (email); edoc |
First, if you are doing native files you don’t need a load file for summation, I know for sure. Also, you don’t need to supply txt files for a native, that is just a waste of a clients money. A near native production should never be considered, that is just a waste almost all software can now handle native files. The true problem with native productions is that attorneys are worried that someone will alter that document which is crazy. If an attorney did that they would be disbared and sanctioned so there is no need to worry plus if you can always ask the judge to order a hash value screening of the original or a shaw evaluation. Tiffs should be forgotten about, I know that most of the software is set up on them but multi page pdfs are much more reasonable. Especially for smaller firms that cannot afford lit support software. The most important thing is to push for native productions, to many files were never intended to be printed, ie excel docs. This description makes something simple way to complicated.
A few comments:
1. I think paper-based documents should be considered in the development of these standards. My experience has been that few document productions are composed entirely of native files. As such, the standard’s methods should be as applicable to the production of scanned paper-based documents as to the production of native and imaged native documents.
2. Regarding color images, I feel that LZW compression should be considered over JPEG compression. LZW compression is lossless and tends to yield smaller files than JPEG (though JPEG will yield higher compression ratios for complex or “noisy” documents, such as photographs).
3. A standard resolution should be suggested for images (e.g., 300 PPI by 300 PPI).
4. I agree with Brian Conrad’s suggestion of slip sheets for non-converted native files and exceptions. While eliminating numbering gaps, I feel that it also helps to eliminate the potential for confusion.
5. I agree with Gillian Glass (and subsequently David Baldwin) that RCDTYPE should be simplified. Perhaps limiting the field to “SCANNED”, “EMAIL”, and “EDOC”?
6. I agree with David Baldwin (and subsequently Thomas Bonk) that the PARENTID/ATTACHMENTID construct is a poor method. I would prefer a single FAMILY field containing the DocID range of the family group, with the lowest DocID being that of the parent.
7. I agree with David Baldwin that externalized document unitization should be eliminated; however, I disagree with his suggestion of the use of multi-page file formats. While single-page format is a relic of paper-based productions, as Thomas Bonk alluded to, multi-page file formats can cause severe performance issues in networked environments. I suggest the inclusion of such unitization information in the DocID itself (e.g., BATES000001_000001). Such a numbering structure is also far more appropriate for use with native documents (i.e., a native file would be identified as BATES000001 and its associated rendered images would be identified as BATES000001_000001, BATES000001_000002, etc.)
7. I completely disagree with Jay Spencer’s comments. A data file should always be produced with native files to ensure consistency among the parties. Similarly, parties should be encouraged to supply extracted text and OCR files for native files, which allows for consistent search capabilities in productions involving any combination of scanned documents, non-searchable native documents, and searchable native documents. A near-native (i.e., TIFFed native file) production format is preferable to a pure native format in that i) it allows for the petrifaction of native documents; ii) it allows for Bates and confidentiality endorsement; and iii) negates the potential for issues caused by proprietary native document formats and software rendering differences. Additionally, production in a petrified (i.e., non-native) format is preferable not because attorneys might intentionally alter such a document, but simply because it is incredibly easy for someone to inadvertently and unintentionally alter such a document.