WalkingPDF

checker

The DAT row with nothing behind it

A load file is a list of instructions: this document, these pages, this image. When a row points at a file that is not in the production, the platform importing it either skips the document or refuses the load. Either way the set that was served and the set that was described are not the same set.

The four ways a load file stops matching its production

The first three are counted in rows and files. The fourth is counted in pages, and it is the one that survives a visual check of the folder, because every file is present and every file opens.

  • **A row with no file.** The document was listed, then the image was left out of the folder that was zipped and sent.
  • **A file with no row.** An image was added after the load file was generated, so it imports nowhere and is invisible to review.
  • **A name that differs only by case.** `Exhibit-A.pdf` in the DAT, `exhibit-a.pdf` on disk. Fine on Windows, broken on the Linux server that imports it.
  • **A break that disagrees.** The OPT says a document ends at page 40; the PDF has 42 pages, so every page after the break is attributed to the wrong document.

Why the receiving side finds it first

The producing party generated the load file from the same working folder the images came from, so on that machine everything resolves. The set that travels is a copy - and a copy is where the case-sensitivity, the missing image and the stale row appear. The first person to import it is the other side, on a platform you do not control, and the first message you get is that the production did not load.

What the check reports

Every DAT row is resolved against the files actually in the set, and the rows that point nowhere are named by line number and by the path they expected. Files no row references are named separately, because an unlisted image is a document the other side cannot find. Page ranges in the DAT and document breaks in the OPT are compared to the page counts of the PDFs they claim, and a case-only mismatch is called out as its own failure rather than folded into "missing", because the fix is a rename rather than an export.

Check this set for it now

Upload the PDFs you are about to serve, plus the DAT and OPT if you have them, or one ZIP of the folder. The verdict, the file list and the worst findings are free. You pay only if you want the certificate, the report and the findings CSV to hand to somebody else.

The verdict, the file list and the worst findings are free and stay free. The certificate, report, findings CSV, manifest and deficiency report unlock on payment, from $49 for a set up to 1,000 pages. The three sizes.

Frequently asked questions

Which load-file formats are read?

DAT files in the Concordance delimiters and OPT files in the Opticon format, including the encodings real exports use. A load file that cannot be decoded is reported as such rather than guessed at, because a wrong guess invents rows that are not there.

Does the check need the load file to run?

No. The pages are read directly, so numbering, text layers and redactions are checked without one. Supplying the DAT and OPT adds the reconciliation checks - rows, orphans, breaks and page ranges - which cannot be inferred from the PDFs.

Can a load file be fixed after it is served?

It can be re-served, which is the cost. A corrected DAT and OPT with a transmittal explaining the replacement is the usual cure; the expensive part is that the other side has already started review on a set that did not load properly.

Keep reading

hub What we check, and what each check means Seventy checks run against a production. Each one is a deterministic read of the files - the stamps on the pages, the structure of the PDF, the rows of the load file - and each returns a pass, a warning or a blocker with the file and page it came from. Nothing here is a model's opinion, and nothing here is claimed on the certificate unless it actually ran. 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. guide The production index columns that matter A production index is the map between Bates numbers and documents. The columns that matter are the ones a receiving party will use to load, search and object: Bates begin, Bates end, attachment begin and end, confidentiality, document date, document type, the original filename and the native path. Everything else is convenience. Get these wrong and the set loads with documents attached to the wrong parents. guide How to QC an incoming production A production you receive has to load, read and reconcile before anyone can review it. These twelve checks run in the order that surfaces the expensive failures first: does the load file import, does every row have an image, does the numbering hold, and is every page searchable. Run them before the review clock starts, not after. checker A Bates number that appears twice A duplicate Bates number means two pages answer to the same citation. In a review platform the second one overwrites or collides with the first; on paper, a request to "turn to ABC000418" has two answers. It is one of the few production defects that is always wrong, because there is no protocol in which two pages may share a number. checker The stamp prints over the words A stamp placed on top of body text makes the words it covers unreadable in the copy that gets served, and a stamp placed too close to the paper edge is cropped by the printer or the scanner. Neither changes the file's numbering, so neither is caught by counting anything - it is a check of where the glyphs actually sit.