The index that ties a document production together
When one party produces documents in litigation, they do not hand over a bare folder of images. Alongside the TIFFs, natives and text files they include a load file: a plain-text index that tells the receiving party's review software what each document is, where its pages live, and how documents relate to each other. Without it a production is an undifferentiated pile of images; with it, a review tool rebuilds the document set, the metadata and the families.
| Metadata load files | Image load files | |
|---|---|---|
| Row granularity | One row per document | One row per page |
| Carries | Named fields — Bates ranges, custodian, correspondence, dates, extracted text | Image key, volume, file path, document-break flag, page count |
| Common formats | Concordance DAT, CSV | Opticon OPT, IPRO LFP |
| Looks like | ¶-delimited, þ-quoted records (DAT) or RFC 4180 (CSV) | Seven comma columns (OPT) or IM command lines (LFP) |
The two describe the same documents from different angles, which is why converting between them means expanding a Bates range into page rows, or collapsing a page run back into a range — never losing the families on the way.
The unique page identifier stamped on every produced page: a fixed alpha prefix plus a zero-padded counter — ABC0001, SMITH-000123. A document spans the inclusive range from its BEGBATES to its ENDBATES; PAGECOUNT should equal the span. Because the whole system rests on that sequence, the classic pre-production check is a gap/duplicate audit: page ABC0007 missing between ABC0006 and ABC0008 means a page was dropped somewhere between imaging and export.
An email and its attachments are separate documents that must review together. The convention: every family member carries a BEGATTACH (and usually ENDATTACH) equal to the parent's Bates range. Review tools group on it. A converter that reorders or splits rows without honoring it detaches attachments from their parent — a quality problem review teams find the hard way.
Concordance DAT files use characters chosen to be absent from real text: the field delimiter is a control character (ASCII 20, commonly written ¶), the text qualifier is þ, and in-value line breaks are stored as ®. Open one with comma assumptions and you get a single garbled column. The DAT guide covers the grammar in detail.
Do it in the browser and the production index never leaves the machine. The converter does exactly this; the Bates checker audits sequences and cross-file consistency.
A DAT is metadata — one row per document. An OPT is an image cross-reference — one row per page. A production usually includes both.
No. The desktop suites cost four figures; the conversions themselves are deterministic text processing, and doing them client-side is enough. Free for small jobs, one-time license for larger ones.
Convert the DAT to CSV first — renaming the extension changes nothing, the delimiters are still control characters. Edit, then convert back.