Why Your Production Won't Load Into Another Review Tool

Most productions that refuse to load fail in the load file, not in the permissions.

A load file is the delimited index that travels with a production: the DAT carries each document's metadata and the paths to its natives and extracted text, while the OPT tells the importer precisely which page images belong to which document. When a production refuses to open in a second review tool, the fault most often lives here, in a path that points to the wrong folder, a field too long for its destination, or a date field mapped as plain text. Nor does every production arrive as a DAT: in a June 2026 explainer video, Evan Brooks, a self-styled certified support engineer, explained DII, the Summation load file, and said Relativity, Everlaw and Logikcull import it through their load-file wizards, where the user selects the format, chooses the field mappings and supplies the paths to natives and images.

I find that diagnosis quietly liberating. An access problem belongs to someone else's help desk. A structure problem can be read slowly, line by line, by anyone patient enough to open the file in a plain text editor and follow each delimiter to its proper place.

None of this is new. Published production guidance held in 2009 that no one could accurately know what a requesting party would need or want without talking about it ahead of time, and urged that the parties' discussions include technical specifications for the format each requesting party needs delivered. What follows reads a stalled production the way an importer does, beginning with how it was packaged and ending with the fields it carries.

Why does a production refuse to load when you have full access?

A production that will not load cannot be reviewed at cents per document, and most such failures come from how the load file is built, not from who holds access.

Before anyone files a ticket about permissions, three plain questions deserve answers, in this order:

1. Is the job an import of a production, or a processing job meant for raw data?
2. Does the delivery arrive as one folder tree, or as many separately zipped pieces?
3. What, precisely, does the error report name: a field, a path, or nothing at all?

The common assumption is that a failed load means a locked door. Gartner Peer Insights, in its market definition of e-discovery software, describes processing as its own stage, the work of reducing volume through deduplication, running OCR or converting data for review, which is a job a finished production has already been through. A May 2026 thread on Reddit's r/ediscovery lays out the classic case in slow and painful detail. A small firm without e-discovery software of its own received a production as 105 separate zip files, each holding NATIVES, IMAGES and TEXT subfolders, while the DAT and CSV sat apart in one more zip. The onboarding representative had the poster extract a single zip inside the platform, drop the DAT into it, and run a processing job, which "immediately came up unknown error." The next suggestion was to copy the DAT by hand into all 105 zips.

Nobody in that story lacked access. A commenter with "over 10 years of experience with ediscovery processing and loading" named the true fault in one line: a production is imported, not processed, because it is not raw data. The DAT creates the records. Its fields are mapped to the platform's fields. The images then follow through an image load file of their own. In practice, the error message was honest. It simply spoke a language nobody at the table was reading.

Volume was not the villain either. Just as a bigger document set does not always mean a longer review, a bigger production does not always mean a harder load; a well-assembled delivery of any size settles into a review platform with the quiet, satisfying click of a properly seated drawer.

Why this matters now is economic before it is technical. At Relevant e-Discovery, our position is that review economics must be demonstrable rather than asserted: AI-assisted review runs cents per document against dollars per document, and roughly $19K/GB, for manual review. Not one cent of that difference is realized while a production sits in a failed queue. Defensibility waits as well, since immutable originals with content hashing, append-only audit trails and documented chain of custody only protect records that have actually arrived. Our view is that Bates numbering, privilege and chain of custody belong in the same tool as cited Q&A and chronologies, which means one import to get right rather than two.

Before a second attempt, ask the producing party for the specification that travelled with the volume: which load-file format it used, which fields the DAT carries, and which folder holds the image load file. To see why one platform's intake differs from the next, you have to open the load file itself and read, line by delicate line, what it is made of.

Why do newer importers reject productions that older tools accepted?

Newer importers are stricter, not friendlier, and a broken path pointer also breaks the link from any answer back to the exact exhibit it came from.

Contrary to the hope that each new platform release makes productions plug-and-play, the evidence points the other way. A November 2023 thread on r/ediscovery, started by a RelativityOne system administrator, recorded the friction as Relativity retired its Relativity Desktop Client (RDC) in favor of Import/Export, with an official deprecation date of 12/31/23. Where RDC had shown its settings in two tabs, one commenter counted 9 pages of options in the replacement.

The stricter rules were structural, and they bit precisely where productions are most fragile:

• Load files had to be packaged in a particular structure inside a .zip file.
• An OPT file in the wrong location inside that zip could not be selected or redirected, a real problem because a great many deliverables keep their load files in a DATA folder.
• An empty nativelink field, which happens whenever only some documents in a load file carry natives, threw an error.
• Exports did not always respect the text encoding that had been set, and metadata fields came out sorted alphabetically.

The export side keeps shifting as well: in a 2025 practitioner thread on metadata redactions, one commenter reported that Relativity had begun letting users edit field names when exporting a production, though that commenter had not yet tested it, so the field list a receiving tool must map can differ from one export to the next. Each of those failures was a matter of shape. One team in the thread spent "hours upon hours" adopting the tool and opened "dozens of support tickets with critical issues." The workaround they settled on was humble: break uploads into smaller zip files and packages wherever possible.

The lesson for a receiving firm is sobering. A production built for one importer is not neutral. It carries the habits of the tool that made it, much as a sauce carries the faint, unmistakable memory of the pan it was reduced in. Platform change also arrives on the vendor's calendar rather than the matter's, a pattern that runs through why your AI review vendor can swap models mid-matter as well.

Here the tension sharpens, because a broken pointer does more than stall a load. On our platform every answer links back to the exact exhibit it came from, so an attorney can verify it with one click before filing, which is the structural answer to the sanctions risk made famous by Mata v. Avianca. That chain of reference is only as sound as the text and native paths beneath it. A misdirected path field quietly severs it. For the same reason, our demo asks buyers to bring a messy collection and a hard question, then watch the system read, code and cite their own evidence rather than read a case study about someone else's. A clean sample proves nothing about a production that arrived in pieces.

Trust adds one more consideration. Relevant e-Discovery deploys inside the client's own AWS account under the client's own keys, a posture almost no small-firm tool can match, and that matters when the files on the repair bench belong to the opposing party. The harder question is what, precisely, to repair, and the practitioners who correct DAT files by hand have a remarkably consistent answer.

What actually breaks inside a DAT file, and how is it repaired?

Fix the DAT where the evidence stays under your control: correct the path pointers, field limits and field types first, inside a single-tenant or in-account environment with no vendor retention.

A DAT file is a delimited text file in which each line holds one document's metadata, each field is divided from the next by a delimiter character, and a text qualifier wraps each value so that commas or line breaks inside it are not mistaken for structure. It is a delicate thing. A 2023 practitioner thread on correcting DAT files named the usual culprits plainly: the most common error was where the DAT points the text or natives field, followed by field character limits and fields mapped to the wrong type. The original poster added that Relativity and Everlaw both reported why a load failed, and that the cause was usually "the dat file, page count or overlapping."

The repair itself, as one commenter in that thread laid it out, ran in five plain moves:

1. Open the error file.
2. Inspect it for issues.
3. Make mass replaces, usually.
4. Save.
5. Append or overlay.

The tools named were text editors such as Notepad++, Sublime Text and EmEditor, plus ReadySuite, with Excel kept for "select situations." There is good reason for that caution. A 2016 thread on DAT manipulation tools warned that Excel can corrupt date fields and that rebuilding the delimited file afterward is painful; the remedy described was to move the data into a text editor, swap tab delimiters for Concordance delimiters as needed, and use regular expressions on the text qualifiers. In 2016, ReadyConvert was quoted at a 14-day free trial and then "around $279" for the full version.

How long does it take? "Sometimes you can fix it in 10 minutes and sometimes it will take hours," one 2023 commenter wrote. Most repairs are mechanical. A few are not. Any edit that touches metadata values, rather than paths or delimiters, deserves a slower second look, because the same 2016 thread carried a sharp warning that altering a DAT after export may not be defensible. On the receiving side, I would keep the produced original untouched, work only on a copy, and log every replace made to it.

Where that copy lives matters. Our processing runs single-tenant, or inside your own AWS account under your own keys, with no vendor retention and no model training, so a repaired opposing production never trains anyone's model. Our platform was also built to be operable and affordable for a solo or small firm on a single messy matter, the very reader who has no administrator to call when an import fails. The arithmetic of buying a tool versus paying a vendor belongs alongside the larger question of what a small firm should pay for a per-matter or annual platform. Still, the finest repair is the one never needed, and that begins at the table where the form of production is first agreed.

What should change before the next production arrives?

Settle the load-file specification before anything is produced: folder layout, delimiters, encoding, path fields and field types, agreed in writing, so the receiving tool accepts the volume on its first import.

Start by asking your own review platform which load-file specification it accepts, so the conference has something concrete on the table. The agreement can carry the awkward cases too, and I find one example from a 2025 practitioner thread on metadata redactions instructive: a commenter described putting into the ESI stipulation that metadata for redacted documents may be incomplete, then scrubbing fields such as TO, FROM, CC, BCC and SUBJECT on those documents. Rule 26(f) requires the parties to confer "as soon as practicable" and at least 21 days before a scheduling conference, on issues "including the form or forms in which it should be produced."

That conference is where I would spend the effort. As of 2020, Rule 34 left a reasonably usable form undefined, so the gap is filled by whatever the parties write down. Native versus image is too coarse a choice. It names the dish and ignores the seasoning.

I expect the next year or two to push these agreements down to the field level: the delimiter and text qualifier, the encoding, the folder that holds the OPT, the type and length of every date field. Importers have grown stricter, as Relativity's 2023 retirement of RDC in favor of a zip-bound Import/Export made plain. The protocol should state, precisely, whether an empty native link is an error or simply a document that never had a native.