What Is a Load File in E-Discovery? A Clear Guide to Formats and Uses
In e-discovery, a load file is a structured text file that tells review software how to organize and display documents produced for litigation, an investigation, or a regulatory matter. It can connect document images to metadata, identify individual pages, and link native files such as spreadsheets or emails. Understanding what a load file does—and what it does not contain—helps legal teams prepare, transfer, and validate productions more reliably.
What Is a Load File?
A load file is a machine-readable companion file used to import a document production into an e-discovery review platform. It contains instructions and data that help the platform associate each document with information such as its Bates number, file name, date, author, and document type.
The phrase “load file” often refers to one or more delimited text files included in a production. The exact structure varies by software, vendor, and production agreement. Common examples include Concordance DAT files, Opticon OPT files, and image cross-reference files. These are conventions, not universal legal requirements.
A load file is not necessarily the evidence itself. The actual evidence may be provided as TIFF or PDF images, native files, or a combination. The load file helps the receiving system connect those items and display them consistently.
What Information Does a Load File Contain?
A load file typically contains a record for each document, or sometimes each page, depending on the format. Each record is made up of fields separated by defined characters. A document record might include a beginning and ending Bates number, a document type, and a link to the corresponding image or native file.
Common fields include:
- Document identifiers: Beginning and ending Bates numbers, document ID, or family ID.
- Metadata: Author, recipient, sent date, subject, file name, file type, and custodian.
- File paths: Locations of images, natives, or extracted text within the production folder.
- Page information: Page number, image sequence, or page-level links.
- Review information: Redaction, confidentiality, or issue fields, when included in the agreed production.
Not every production includes every field. The parties or their vendors may agree on a specific field list, naming convention, and format before production. Metadata may also be absent when it is not relevant, cannot be reliably extracted, or is not required by the production protocol.
How a Load File Works With Production Materials
Think of a load file as a map or index for a production. It tells review software which files belong together and where to find them. Without a usable map, reviewers may still have the images or native files, but importing and organizing them can take extra time and may result in missing associations or incomplete metadata.
A typical production may include:
- Load files: Structured records and links for importing the production.
- Image files: Rendered pages, often in TIFF format, with Bates numbers applied.
- Native files: Original files, such as spreadsheets, presentations, or audio files, when produced in native form.
- Extracted text: Searchable text associated with documents or pages.
For example, an email with two attachments may appear as a family of related records. The load file can identify the email and attachments, preserve their relationship, and point to the files or page images associated with each item. The exact family structure depends on the production design.
Common Load File Formats
Several formats are widely used in litigation support. Their names are often associated with particular software histories, but they may be accepted by multiple platforms. A recipient should confirm that the receiving system supports the supplied format and that the required delimiters and field definitions are documented.
| Format | Typical use | Important detail |
|---|---|---|
| Concordance DAT | Delimited text records, often containing metadata and file paths | Field separators, text qualifiers, and encoding must be interpreted correctly. |
| Opticon OPT | Image cross-reference information | Often maps Bates numbers to image file names and page positions. |
| CSV or other delimited text | Metadata exchange and custom imports | Column order, quoting, and delimiter rules should be specified. |
| Native-file links or custom files | References to original files or specialized production data | Folder structure and path conventions must remain intact. |
DAT and OPT are frequently delivered together, but they do different jobs. A DAT file commonly carries document-level metadata and references, while an OPT file commonly provides image-level information. The precise roles can vary, so the production specification should explain how the files relate.
Why Load Files Matter in E-Discovery
Load files support the transfer of large document collections between parties, law firms, service providers, and review platforms. Their value is practical: they reduce manual data entry, help preserve relationships, and make productions easier to search and review.
- They support efficient review. Metadata can be filtered and sorted, helping reviewers find documents by date, custodian, or file type.
- They connect related materials. Family identifiers and file paths can associate emails with attachments and records with images.
- They help preserve production structure. Bates ranges, page sequences, and file references can be imported in a consistent way.
- They make quality checks possible. A receiving team can compare listed records against the files delivered and identify missing or mismatched items.
A load file does not establish that a production is complete, authentic, or legally sufficient. It is a technical component of the delivery. The parties still need to address relevance, privilege, confidentiality, production format, and applicable procedural requirements.
Load Files and E-Discovery Rules
In U.S. federal civil litigation, Federal Rule of Civil Procedure 34 addresses the form in which electronically stored information (ESI) is produced. If a request does not specify a form, the producing party generally must produce ESI in the form in which it is ordinarily maintained or in a reasonably usable form. A load file is one possible component of a production, but Rule 34 does not require a single universal load-file format.
Production details are often addressed through agreements, discovery requests, case-management orders, or local practices. The parties may specify metadata fields, image formats, native-file handling, text, Bates numbering, and load-file conventions. The U.S. Courts’ Federal Rules of Civil Procedure provide the governing text; case-specific agreements and orders should be checked as well.
The Electronic Discovery Reference Model (EDRM) offers a framework for understanding e-discovery activities, including processing, review, and production. It is an industry model rather than a substitute for court rules or a case-specific production protocol.
How to Prepare and Validate a Load File
Preparation begins with an agreed production specification. Before export, the producing team should confirm the target format, field names, date conventions, character encoding, delimiter rules, folder structure, and treatment of natives and attachments. A receiving team should obtain the same specifications so it can configure the import correctly.
- Confirm the schema. Document each field, its meaning, and whether it is document-level or page-level.
- Check delimiters and encoding. Characters used as separators can also appear in document text. Quoting, escaping, and encoding rules help prevent values from splitting or displaying incorrectly.
- Verify file paths. Confirm that every referenced image, native, and text file exists in the delivered folder structure.
- Compare counts. Reconcile records, documents, pages, and files against the production manifest or agreed totals.
- Test representative items. Import examples with long text, special characters, attachments, redactions, and native files.
- Preserve a clean copy. Keep the original delivery intact and perform import troubleshooting on a working copy.
Automated validation can identify duplicate identifiers, broken paths, blank required fields, unexpected delimiters, and mismatched page counts. A test import is especially useful because a file can appear structurally sound in a text editor yet fail when interpreted by the target platform.
Common Load File Problems and How to Address Them
Incorrect delimiter or text qualifier
Delimited files may use unusual characters to separate fields or mark text values. If the import settings do not match the export, commas, quotation marks, or other characters inside a field can shift data into the wrong columns. The production documentation should state the delimiter and qualifier, and the import should be tested before full processing.
Broken or incorrect file paths
A load file may point to files that were renamed, moved, or omitted from the delivery. Relative paths can also fail if the folder layout changes. Maintaining the original folder structure and checking all references can prevent missing images or natives.
Missing or inconsistent metadata
Fields may be blank, use inconsistent date formats, or contain values in an unexpected encoding. Some blanks are appropriate, such as when a document has no author metadata. Validation should distinguish expected gaps from extraction or export errors.
Page and record mismatches
A document record may not match the number of images or pages supplied, or page-level references may point to the wrong sequence. Reconciliation of document IDs, Bates ranges, and image totals can reveal these issues. Any correction should be documented and coordinated with the producing party.
Load Files, Native Files, and Images: Key Differences
These terms describe different parts of a production. A load file organizes and links information. An image is a rendered representation of a document page. A native file is the original electronic file, such as an Excel workbook or PowerPoint presentation. Extracted text is searchable text derived from a document or file.
Not every file should be treated identically. A spreadsheet’s formulas, hidden rows, and workbook structure may be important, while a TIFF image may show a fixed page view. Production instructions should specify when native files are required and how they are named and linked. A load file can assist with those links, but it does not convert a native file into an image or replace the native content.
Questions to Resolve Before a Production
Clear technical instructions reduce avoidable disputes and rework. Before producing or receiving ESI, teams can address the following questions in writing:
- Which load-file format and software import profile will be used?
- Which metadata fields are required, and what does each field represent?
- Will the production include images, natives, extracted text, or a combination?
- How will email families, attachments, and embedded files be represented?
- What Bates-numbering and page-count conventions apply?
- How will redactions and confidentiality designations be reflected?
- What validation reports and error-correction process will be provided?
These details can be set out in a production protocol or technical specification. If a production problem arises, preserving the original files, recording the error, and communicating specific examples usually makes resolution faster than changing import settings without documenting the change.
Practical Takeaway
A load file is the structured guide that helps e-discovery software import and connect production materials. Its effectiveness depends on a clear schema, valid file references, compatible delimiters, and agreement about how records, images, text, and native files fit together. Because no single format is required for every matter, the most reliable approach is to define production specifications in advance and validate the delivery with a test import and reconciliation checks.