LegalFree
Relativity Load File Production QC
River validates the .dat, the .opt and the file sets against each other, then tells you which defects are yours and which are theirs.
A production is at least three artifacts that have to agree with each other: the .dat carrying the metadata, the .opt carrying the images page by page, and the folders the paths point at. Nothing in the set validates the other two. River reads all three together and reports the disagreements line by line. Each one carries the Bates range it affects, what the platform will do when it reaches that line, and whether the fix is yours or a call to the producing party.
The list splits two ways, because the two halves go to different people. A path pointing at a native that is not in the volume is a defect in the production and belongs in a letter to the producing party. An encoding the platform will not accept is a defect you fix on ingest without telling anyone. This is two artifacts that disagree with a chain of custody attached, so reporting both halves together produces a letter full of things you could have solved yourself.
This runs at the front of a review, before anybody codes a document. What comes after it is reviewing the set and proving each privilege claim, which assumes the Bates ranges are what they say they are. Get that wrong here and a privilege log cites ranges that do not exist in the load, a clawback letter names documents nobody can find, and every count in the review register is measured against the wrong denominator.
The same vendor asks for two different encodings
Relativity's own documentation is the clearest evidence that the encoding failure is structural rather than careless. The Desktop Client path requires .opt files in ANSI or Western European encoding and does not support Unicode, telling you to resave any Unicode file. The newer Import/Export path in RelativityOne says the opposite: save these .opt files using UTF-8. One vendor, two live paths, opposite answers. So an .opt that is correct for one workspace is rejected by the other, and nothing in the file says which it was built for.
The page count is the other one, and it fails quietly. Field seven of an Opticon line is where a page count goes, and Relativity's documentation says it is not required and not used. So the load succeeds and the number is discarded. Document boundaries come from field four instead, a Y on the first page of each document, which means one dropped Y merges two documents into one and nothing in the load complains.
And the platform's own check is a sample. Import/Export runs a precheck that reads 1,000 random lines across the whole load file, which is a sensible design and not a validation. On a 62,000-row production it touches under two percent, so a broken path block starting at line 41,000 clears the precheck and stops the load an hour in. Reading every line before the upload costs nothing and is the only way the count is real.
How it works
Hand over the volume
The .dat, the .opt, the image and native folders, and the ESI protocol if one was entered.
Files get reconciled
Bates ranges, document breaks, page counts and paths are read across all three artifacts at once.
Defects get sorted
Each finding lands as yours to fix on ingest or theirs to answer, never both.
The letter drafts itself
Production defects come back written as points for the producing party, each with its line numbers and Bates range.
What you get
- Every line of the .dat and the .opt read, not a thousand-line sample
- Encoding checked against the import path the production is actually going into
- Document breaks in the .opt reconciled against the Bates ranges in the .dat
- Every image and native path resolved against the volume, with the orphans counted both ways
- Each defect marked as yours to fix on ingest or theirs to answer for
- Field counts, delimiters, embedded returns and the rows where the columns stop lining up
Common questions
What formats does it read?
Concordance-delimited .dat with the standard thorn and pilcrow characters, comma-delimited CSV, and Opticon .opt, plus the image and native folders the paths point at. It reports the delimiters and encoding it detected before it validates anything, because a file parsed under the wrong assumption produces sixty thousand false findings.
Do I need the images to run it?
No, and it says which checks it skipped. Without the image folder it still reconciles Bates ranges against document breaks, validates encoding and field counts, and lists the paths it could not test. Run it on the load files alone the moment the volume lands, then again once the transfer finishes.
Is a defect grounds for going back to the producing party?
That is your call, and the split makes it easy to see. Where a request did not specify a form, the rule requires production in a form in which it is ordinarily maintained or a reasonably usable form. Whether a particular defect clears that bar is a shorter argument where the form was agreed up front, so the output gives you the defect, the count and the affected ranges.
What about a production we are sending out?
Same run, opposite direction, and the defects are cheap before service. The checks do not change: encoding for the receiving platform, document breaks agreeing with the Bates ranges, every path resolving, no orphaned natives. It is also the moment to check whether the redactions actually removed anything. What changes is that every finding is yours, and there is nobody to write to about it.
Why does the page count matter if the platform ignores it?
Because everything downstream does not. A page count in the load file that disagrees with the images on disk is the earliest visible sign that a document was split, dropped or slip-sheeted. The load will not tell you. It is the same shape as a matcher with a documented blind spot: correct, scoped, and mistaken for the whole picture.
What happens after the load is clean?
The set becomes reviewable, and the next problem is proving what you withhold. Writing each entry to the elements of the privilege claimed depends on Bates ranges that resolve, which is why this runs first. A log citing a range the load never contained is the kind of error opposing counsel finds for you. A deposition digest citing the same exhibit fails the same way.
Does it fix the load file?
It tells you exactly what to change and where. Re-encoding an .opt, repairing a delimiter or repointing a path block is a small, reversible edit somebody should make deliberately, on a copy, with a record of what was altered. A silently rewritten production is not a production you can vouch for.
Relativity Load File Production QC
Fill in the form and your workspace opens with the work already underway.