Load file

What it is made of

A conventional production has two load files doing different jobs.

An image load file, traditionally with an .opt extension, maps image files to documents and marks where each document begins. It is what stops a platform from treating four hundred loose page images as four hundred separate documents.

A data load file, traditionally .dat, carries the metadata: the Bates range, the custodian, sender and recipients, the date sent, the subject, the path to extracted text, and the parent-child fields that tie an attachment to the message that carried it.

Both are delimited text. The .dat format conventionally uses unusual delimiter characters rather than commas, precisely because commas and quotation marks appear constantly in email subject lines.

Why it is fussy

A load file is machine input, and platforms reject malformed ones with error messages that rarely say what is actually wrong. Field order, delimiter characters, date formats, encoding, and path separators all have to match what the receiving specification asked for. This is why production protocols specify them in tedious detail, and why the tedious detail is worth reading before imaging several hundred documents.

Where the contents come from

Not from the images. Every metadata field in a data load file is extracted from the native file — for email, from the .eml or .msg original. So is the extracted text that makes an imaged production searchable.

That is the practical reason natives are retained through the whole process even when the delivery is images: once you have imaged an email and thrown away the original, the metadata needed to describe it is gone.

When you need one

When you are producing into a review platform, which usually means a TIFF production or an imaged PDF set delivered under a protocol. You do not need one when a handful of emails are going in as exhibits to a motion — that is just PDFs with Bates numbers.