guide
Why a load file fails to import, and what it means before you serve
A load file is a delimited text file that maps each page of a production to the fields a review platform needs: the Bates number, the document break, the family relationships and the file path. When it fails to import, the cause is almost always structural - a row with the wrong number of columns, a delimiter inside a field, a page number that does not exist in the images, or a path that points nowhere. All four are detectable by reading the DAT and the images together, which is what the check does.
What a load file actually is
Two files usually travel together. The DAT (or CSV, or delimited text) holds the metadata: one row per page or per document, with columns for the Bates number, the document identifier, the parent and attachment identifiers and the relative path to the image or native file. The OPT (or image cross-reference) maps each page to its image file.
Import fails when the relationship between those files and the images breaks. The platform reads the first rows, builds a schema from the delimiter and the column count, and rejects the load when a later row contradicts that schema.
The six failures behind most failed imports
- A quoted field contains the delimiter, and the quote handling in the file does not match what the platform expects.
- One row carries a different number of columns than the header - usually because a value contained a newline.
- The Bates number in the DAT does not exist among the produced images, so the row points at a page nobody produced.
- The path column is absolute, uses backslashes, or names a folder that is not in the delivered structure.
- Parent and attachment identifiers do not resolve: a child names a parent that is not in the file, or a family is split across two deliveries.
- Character encoding is not what the platform assumes, so a name with an accent arrives as a replacement character and the row is rejected.
What a check can tell you, and what it cannot
Reading the load file against the images can tell you that every row is well-formed, that every referenced page exists, that the page count per document adds up, that identifiers resolve inside the file, and that the Bates ranges are continuous and in order.
It cannot tell you whether the field mapping is the one the receiving platform expects, because that is a convention between the producing and receiving parties. A file can be internally perfect and still be mapped wrongly. The report says which of the two you are looking at, rather than implying the first means the second.
What to do when it fails
Work from the specific row, not the file. A validator that reports "load file invalid" has told you nothing you can act on; one that reports the line number, the column and the offending value has told you what to fix in a minute. If the failure is a Bates number with no matching image, the question stops being technical and becomes a production question: was that page produced, and if not, why is it in the load file.
Frequently asked questions
Is the DAT the same thing as the OPT?
No. The DAT carries metadata, one row per page or document. The OPT maps pages to image files. A production can have a valid DAT and a broken OPT, which is why checking one and not the other misses half the failures.
Can a load file be fixed after the production has been served?
It can be corrected, but the correction is a re-production and usually needs the other side's agreement. That is the reason to run the check before service rather than after a platform rejects the set.
Does the check verify the field values themselves?
It verifies structure, references and ranges. It does not know whether a date is the right date or a custodian name is spelled correctly - those are review questions, not integrity questions.