Can a load file be fixed without re-producing the volume?

Often, yes, and it is worth asking before anyone re-exports. A path prefix, a wrong encoding or a field order that does not match the agreed list are all corrections to the index rather than to the documents, so the images and natives already delivered stay as they are. A Bates range that is genuinely wrong is a different matter, because the numbers are endorsed on the pages.

What happens if the Bates range and the image count disagree?

The volume is short or long, and which one tells you where to look. A document whose range covers four numbers but delivers three images is usually a failed conversion; four images against a three-number range usually means the document-break flag is wrong. Reconciling the two is one of the checks on the production checklist.

Does a receiving party have to accept any load file format?

Only what was agreed. The form of production is settled between the parties, normally in an ESI protocol, and a volume that arrives in a different format than the one specified can be rejected on that basis. Federal Rule of Civil Procedure 34(b)(2)(E) requires a reasonably usable form; it does not name a file format.

Why does a DAT import put every field in one column?

The importing tool is not seeing the delimiters. A DAT file uses characters well above the ASCII range precisely so they never appear in document text, and a tool told to split on commas or tabs finds none of them, so the whole row lands in one field. Set the qualifier and separator explicitly rather than letting anything auto-detect.

What is the difference between a Concordance and a Relativity export?

For a standard production, very little at the file level: both write a delimited metadata file plus an image reference file, and Relativity's default delimiters match Concordance's. What differs is the field list each platform exports by default, which is why the agreed field order matters more than the platform that produced it.

DAT and OPT load files explained: how to read one

A load file is the index delivered with a production: it tells the receiving platform which images, which native files and which metadata belong to which document. Most production failures are load file failures rather than document failures, and nearly all of them are visible in the first row, the file encoding, or a page count that does not reconcile.

How do you read a DAT row?

Field by field, against the agreed field order, because nothing in the row labels itself.

This is the same row the DAT file entry shows, with each field named:

þSMITH-000148þ¶þSMITH-000151þ¶þSMITH-000148þ¶þSMITH-000152þ¶þMendez, Janeþ¶þ2024-03-11þ¶þRe: Q1 forecastþ¶þ\NATIVES\SMITH-000148.xlsxþ

Reading left to right: BEGBATES is SMITH-000148 and ENDBATES is SMITH-000151, so this document is four pages. BEGATTACH is SMITH-000148 and ENDATTACH is SMITH-000152, so the family runs one number past the document itself, which means an attachment follows. CUSTODIAN is Mendez, Jane. DATESENT is 2024-03-11. SUBJECT is the email subject line. NATIVELINK points at a spreadsheet, which tells you the attachment at SMITH-000152 was produced natively with a slip sheet standing in for it in the image stream.

Three habits make this fast. Read the attachment range before anything else, because it tells you whether you are looking at a family or a loose document. Treat a populated NATIVELINK as a signal that the image stream will be one page short of what the page count implies. And check the first row against the agreed field list rather than assuming the order, because a field order that differs from the protocol is the defect most likely to survive an import and corrupt every row silently.

Which delimiters and encodings do load files use?

Load file delimiters and the character codes behind them
Character	Role	Code	Where it appears
þ	Text qualifier around each value	ASCII 254	DAT
¶	Field separator between values	ASCII 020	DAT
®	Stands in for a line break inside a value	ASCII 174	DAT
,	Field separator	Comma	OPT

These are the Concordance defaults, which most platforms adopt and which Relativity matches. They sit well above the ordinary ASCII range on purpose: a comma or a quotation mark appears in document text constantly, and a character that never does cannot break a row.

Encoding is the other half and the half more often missed. A DAT written as UTF-8 and read as ANSI, or the reverse, corrupts every character outside plain ASCII, and because the delimiters themselves are above that range, the symptom is not a few odd characters but a file that will not parse at all.

Who generates the load file, and what do you specify?

The review platform writes it during a production export. Nobody hand-writes a load file, and a request to do so is a sign something upstream has gone wrong.

What the producing side chooses at export is the part that matters: the field list and its order, the delimiters, whether images are TIFF or PDF, whether natives are included and how they are referenced, and the volume naming. Each of those should already be settled in the ESI protocol rather than decided at the export screen, which is the whole argument for agreeing format before collection rather than after.

Why do productions fail to load?

Five causes account for most of it, in roughly the order you will meet them.

Encoding mismatch. The file parses as gibberish or not at all, as above. It looks catastrophic and is usually a one-setting fix.

Field order that does not match the agreed list. The import succeeds and the data is wrong: dates in the subject column, custodians in the date column. This is the dangerous failure, because nothing errors.

Path problems. The image or native paths in the file do not match the folder structure delivered, or they are absolute paths from the producing party’s own system. The OPT file entry covers the symptom in detail.

A document-break flag in the wrong place. The Y marks the first page of each document, so a missing or misplaced flag merges two documents into one or splits one into two. The unitization decision is what the flag records, and getting it wrong changes the document count.

A Bates range that does not reconcile with the images delivered. Either pages are missing or the range is wrong, and Bates numbering is endorsed on the pages themselves, so this is the failure least likely to be fixable without re-producing.

What should you validate before sending a volume?

This is a diagnostic pass, not a specification. What a load file must contain belongs in the protocol; what follows is what to check in the file you are about to send.

Open the DAT in a text editor first, not a spreadsheet, and confirm the delimiters are present and the encoding is what you expect.
Check the header row, or the first data row where there is no header, against the field list the protocol names, in order.
Count the rows and compare against the document count the platform reports.
Reconcile the OPT row count against the image files actually in the volume.
Confirm the document-break flags produce the document count you expect, not one that differs by a handful.
Spot-check three families end to end: a loose document, an email with attachments, and a natively produced item with its placeholder.
Confirm every populated NATIVELINK resolves to a file that is present.

Items four through seven are the ones that catch defects an import will not. The production checklist sets the same checks in the wider context of everything else a volume needs before it leaves.

How this works on a flat rate

Kavarn, the flat-rate eDiscovery service Konvergence Inc operates, includes productions and exports in the instance rate. Load file generation is part of the platform license rather than a separate export fee, so re-running a corrected volume after a failed import costs the time it takes and nothing more.

That matters here more than on most pages, because the cost of a load file defect is rarely the defect itself. It is the re-production, and where exports are billed per gigabyte the second attempt is charged like the first. The pricing page publishes the rate, and the Fee Field Guide sets out how export and production fees are usually charged. See what the platform includes, or book a walkthrough.

Sources

EDRM, Production Guide and load-file guidance, which the load file, DAT file and OPT file entries also cite.
The Sedona Conference, Glossary: eDiscovery & Digital Information Management, for “load file” and “Opticon”.
Fed. R. Civ. P. 34(b)(2)(E) on the form in which ESI is produced.
Delimiter characters and field conventions: as recorded in the DAT file and OPT file entries.