What is ESI?
Electronically Stored Information (ESI) refers to digitally created, stored, or transmitted data. ESI includes emails, documents, databases, social media posts, and more. It is integral to legal proceedings and can serve as crucial evidence.
What is an ESI Protocol?
An ESI protocol is a set of agreed-upon guidelines and procedures governing the management of electronically stored information during litigation. These protocols cover the identification, preservation, collection, processing, and production of ESI.
What is an ESI Agreement?
An ESI Agreement is a general agreement negotiated between parties in a litigation setting. It is also known as a discovery protocol. An ESI agreement outlines the processes, procedures, and timeline for exchanging electronically stored information (ESI).
What is the Difference Between an ESI Agreement and an ESI Protocol?
An ESI agreement is a general agreement between the parties involved in a lawsuit that ensures that all parties involved clearly understand the expectations, requirements, and deadlines related to ESI. On the other hand, an ESI protocol details how the parties need to identify, preserve, collect, and produce ESI information during the litigation process.
Why do eDiscovery Productions need an ESI Protocol?
ESI protocols are integral to the eDiscovery process and help streamline it. They are key to maintaining digital data integrity, ensuring compliance with legal requirements, and aiding efficient data management and cost control. They also help preserve privilege and confidentiality, provide transparency, and help legal teams anticipate and manage ESI, reducing uncertainties and managing outcomes.
What are some standard ESI Protocol Specifications?
Generally, ESI specifications will include a production format, standard image format, and load file requirements. Some of the standard specifications are:
-
Production Folders
Standard specifications often organize produced data into IMAGE, NATIVE, and DATA folders. The load file is present in the root folder. At times, there will be a limit to the number of files found in each subfolder. E.g., there should only be a maximum of 1000 files in each sub-folder
-
Required Metadata and Database fields
You will often receive specifications regarding the encoding of metadata load files. For example, Load files should be in Unicode format with Concordance delimiters using the .DAT format. As per the ESI protocol, the file name should be in the first row of each metadata load file. You may need to format the date and time with the format MM/DD/YYYY HH:MM (06/30/2009 13:3), or if the request is for separate fields, the format should be MM/DD/YYYY for the date and HH:MM for the time.
-
Image Files
Single-page image files that have a corresponding load file (.DAT) entry will commonly have an Opticon (OPT) file that provides links to it. Image file names should match the page identifier for that particular image and have the appropriate extension. There are also often restrictions on the file names, such as no embedded spaces, commas, ampersands, slashes, backslashes, hash marks, etc., or any character that is used as delimiters in the metadata load file, or any character not allowed as per Windows file-naming convention.
-
Text
ESI protocols generally give specifications for text files. One specification could be that each document’s text should be in a separate text file with a link to the file in the load file (.DAT). A TEXT folder will usually hold these text files. In such a production, all documents should have a corresponding text file, irrespective of whether they contain text. Also, text processing and delivery should match the encoding of the metadata load file.
-
Native Files
Sometimes, you will need to include native files in the production. This could be for all documents, some specific document types, or only unsupported document types. In such a scenario, the ESI protocol could specify the file naming conventions for the native file. For example, the native file names could start with the Bates number for that specific record.
Commonly requested data fields and corresponding GoldFynch-recognized fields
Category | Field Name | Field Description | GoldFynch Title | GoldFynch Field |
---|---|---|---|---|
All | BEGDOC | The starting number of a document | DOC_BEG_BATES | Doc Begin |
ENDDOC | Ending number of a document | DOC_END_BATES | Doc End | |
BEGATTACH | Starting number for parent document within a group | FAM_BEG_BATES | Attach/Family Begin | |
ENDATTACH | Ending number for child document within the group | FAM_END_BATES | Attach/Family End | |
CUSTODIAN | Custodian(s)/Source(s); Last, First | CUSTODIAN | Custodian | |
CONFIDENTIAL DESIGNATION | Confidentiality designation of a document | unavailable | ||
DOCUMENT EXTENSION | Actual file extension of the eDoc or email | FILE_EXT | File Extension Resolved | |
MD5HASH | Identifying value of an electronic record that you can use for deduplication and authentication generated using the MD5 hash algorithm | MD5_HASH | File MD5 Hash | |
FILE PATH | Path to native file if natives are delivered | NATIVE_PATH | Native Path | |
EMAIL FROM | The sender of the email | FROM | From | |
EMAIL TO | Recipient(s) of the email | TO | To | |
EMAIL CC | Recipient(s) of the email in the "CC" field | CC | Cc | |
EMAIL BCc | Recipient(s) of the email in the "BCC" field | BCC | BCc | |
EMAIL SUBJECT | The subject of the message | SUBJECT | Subject | |
DATE SENT | Date and Time the email was sent | SENT_DATE | Email Sent Date | |
DATE RECEIVED | Date and Time the email was received | RECV_DATE | Email Received Date | |
NUMBER OF ATTACHMENTS | Number of attachments an email has | ATTACH_FILE_COUNT | Child/Att File Count | |
ATTACHMENT LIST | Concatenated list of attachment names separated by semicolons, aka Attachment Names | unavailable | ||
E-Doc | FILE NAME | Name of the original file name aka Filename, Original Filename, Name | FILE_NAME | File Name |
AUTHOR | Author eDoc; Last, First | AUTHOR | Author | |
DATE LAST MODIFIED | Date the eDoc was last modified | LAST_MODIFIED_DATE | Last Modified Date | |
SUBJECT | Subject of the document extracted from the properties of the native file | SUBJECT | Subject | |
HAS HIDDEN DATA | Indication of the existence of hidden data such as track changes in a Word document, hidden columns or rows in an Excel or slide notes in PowerPoint | Unavailable | ||
TRACK CHANGES | The yes/no indicator of whether tracked changes exist in the document | Unavailable | ||
COMMENTS | Comments extracted from the metadata of the native file | Unavailable |