Production formats and load files: the boring thing that causes disputes

A production is not merely a set of documents. It is a package of files, page identifiers, family relationships, metadata, and sometimes extracted text. The receiving organization must be able to load that package into its review platform, identify each item, connect related items, and trace any produced document back to the processing record.

That is why format decisions become operational disputes. A native file may be functionally complete but unusable in the receiving environment. An imaged file may be easy to display and number but discard the functionality the custodian relied on. A load file may be structurally valid but misidentify the files accompanying it. The agreement should describe the production as a system, not as a file extension.

Native, image-based, and hybrid production formats#

A native production delivers the source file rather than a picture of it. This approach best preserves document structure, embedded objects, spreadsheet formulas, and the file’s original metadata. It also allows the receiving organization to work with the document in the format the producing organization controlled.

Native does not mean that every original capability will remain available. The file may depend on an application, operating system, external link, embedded object, or specialized font that the recipient does not have. Active content and custom features can also create security or compatibility issues. Production teams should distinguish between a feature that is absent from the source and one that is present in the source but does not function in the receiving environment.

An image-based production converts each page into a fixed visual representation. TIFF is a common page format for this purpose, and an image-based PDF presents the same basic concept in a page-oriented container. The resulting files generally present consistently because the recipient is viewing rendered pages rather than interpreting an original document.

Imaging loses functionality. Spreadsheet formulas, macros, hidden content, dynamic fields, links, and document layers may not survive the conversion. Original metadata and an email’s family structure generally need to be supplied through the load file or related files. Extracted text can make images searchable, but it is a derivative of the image rather than a restoration of the original document. An OCR-derived passage may also differ from what appears on the page.

Not every file benefits from imaging. A spreadsheet, for example, may convey meaning through formulas, cell relationships, or embedded content that cannot be represented by page images. Imaging such a document can produce a readable record that fails to preserve the information the reviewer needs.

A hybrid production addresses that problem by using native delivery for selected file types and imaging for others. Spreadsheets are a classic example. A common structure is to deliver spreadsheets natively while imaging documents such as email attachments or formatted reports. The producing party should identify the governing rule for each file type rather than requiring the receiving party to infer it from inconsistent extensions or content.

Extension alone is not a reliable format designation. A PDF may be a native file or a collection of page images, and a file bearing a familiar extension may contain a different internal structure. The receiving party should sample the delivered files in the environment in which they will be reviewed.

Why Bates numbering remains central#

Bates numbering assigns a unique identifier, usually to each produced page, so the producing and receiving organizations can refer to the same material. In an image production, the number can be embedded on the page and used as the control identifier associated with the corresponding load-file record. In a native production, numbering may be applied at the document or family level because a single document can contain multiple pages.

Imaged productions remain common even though they cost more to store and deliver and lose some document functionality. The rendered page provides a stable display, and the Bates identifier provides a simple reference for correspondence, disputes, and later production stages. Imaging can also make page-level control easier when documents have different structures.

The numbering scheme should define its unit: page, document, family, or attachment. It should also address ranges, suffixes, confidentiality designations, and any gap or exception. Receivers need to distinguish an intentional gap from a missing file. A load-file field that does not correspond to the Bates mark on the delivered image creates an avoidable reconciliation problem.

What a load file actually does#

A load file is the index that tells the receiving system what the produced files are and how they relate. It may contain one row per document or family, or one row per delivered image. Its metadata travels with the record during import and supports review, family grouping, search, de-duplication, and production tracking.

A delimited load file organizes fields into rows and columns. Each row represents an item or relationship, and fields carry values such as the Bates number, file name, custodian, dates, family identifiers, and text-file reference. The file is conceptually simple, but its meaning depends on an agreed data dictionary and consistent values.

An image-reference load file connects the delivered file or image to a corresponding record. Instead of treating every page solely as a row in the same data structure, the receiving system follows the reference to locate the image and associated metadata. The reference must resolve to the correct delivered file without ambiguity.

A mismatch between the load file and the delivered files is the most common production failure. The files may have arrived, but the receiver cannot determine which image belongs to which Bates number, which email is the parent of which attachment, or which text file contains the searchable content for a document. The result is incomplete review, manual reconstruction, and disputes over completeness.

De-duplication and email threading illustrate the same problem. A document can be removed as a duplicate while its family relationships remain relevant. A parent message may be delivered once while several attachments travel in separate families. The load file must describe the resulting structure accurately; it should not reproduce assumptions from an earlier processing stage that no longer match the production.

Metadata fields that affect the receiving side#

Parties typically negotiate the metadata fields included in the load file and the production protocol. The issue is not how many fields are supplied. It is whether the fields support the receiving organization’s processing and review while remaining consistent with the delivered files.

Metadata quality matters as much as field selection. Dates should follow an identified convention, empty fields should be handled consistently, and document-family values should match the files delivered. The load file should also distinguish between missing information and a field that is present but populated with a null value.

Load-file values should be tested against the source processing record. A metadata field can be technically present while describing a version that was not produced. For example, a file name may have changed during processing, or a document may have been replaced before delivery. Sampling the source, processing output, load file, and final image together exposes those mismatches before production.

The production protocol and objections#

Rule 26(f) requires the parties to confer before the scheduling conference. Rule 16(b) governs the scheduling order. The production format belongs in that conferral process because it affects collection, processing, quality control, transfer, and review on both sides.

The written protocol should address native versus image-based delivery, the file-type rules for a hybrid production, Bates unit and format, load-file structure, metadata fields, family relationships, text delivery, redactions, and the handling of withheld material. Those terms should then be reflected in the discovery protocol or scheduling order. If the parties disagree, the unresolved point should be identified before the production is prepared rather than discovered when the package cannot be imported.

Rule 34(b)(2)(C) requires a party stating an objection to a request to specify whether any responsive material is being withheld on the basis of that objection. That requirement interacts directly with production staging. The receiving organization needs to know whether the production represents the complete responsive set or excludes material for a stated reason.

A privilege log or other written explanation may supplement the production communication, but it should not leave the status of withheld material ambiguous. Likewise, the load file should identify the items actually delivered without implying that omitted material was produced. Staging by issue, custodian, or production volume is possible, but each stage needs its own scope, metadata, and reconciliation information.

Pre-production checks that prevent expensive corrections#

1. Reconcile source, processing, and production populations. Compare the collected population with the processed set, the staged set, the load-file records, and the delivered files. Explain each difference through de-duplication, privilege, redaction, or another recorded basis.
2. Validate load-file references. Confirm that every referenced image and text file exists, resolves to the intended record, and can be opened by the receiving system. Check for orphaned files as well as load-file rows pointing to missing content.
3. Sample the actual deliverables. Open native files in the expected review environment. For imaged pages, inspect legibility, page order, completeness, redactions, and Bates marks. Open spreadsheets separately to determine that the original structure and functionality remain available.
4. Check Bates controls. Confirm uniqueness, explain documented gaps, verify that page identifiers match the load file, and distinguish document-level identifiers from page-level identifiers.
5. Test families and threading. Verify parent-child relationships, attachment references, duplicate treatment, and email-thread assignments against sample records. A load file can import successfully while preserving the wrong family structure.
6. Compare metadata with source records. Test dates, custodians, participants, file names, source paths, and family identifiers against the processing record. Confirm that empty values and date formats follow the agreed convention.
7. Verify text availability. Search the extracted text, confirm that its reference resolves to the correct document, and compare sampled passages with the image or native file. Extracted text that cannot be mapped to its source can produce misleading review results.
8. Reconcile redactions and withholding. Confirm that redactions are visible, that privileged content is not included in native files or text derivatives, and that the communication required by Rule 34(b)(2)(C) accurately states whether responsive material is withheld on the basis of an objection.
9. Perform an independent import test. Load the production into the receiving platform before delivery. This exposes invalid field lengths, unsupported encodings, broken references, duplicated control numbers, and family relationships that fail to import as intended.