WalkingPDF

guide

How each check is verified

A check that fires on a clean production is worse than no check: it teaches the reader to ignore the report and it makes the certificate worthless. So every rule here is held to two files, not one.

Two files per rule, and the second one is the hard part

Each rule has a fixture that contains the defect and a fixture that looks close enough to trip it but is correct. The defect file proves the rule can fire. The clean file proves it does not fire on a production a lawyer would serve, which is the failure that actually costs a buyer trust.

The clean fixtures are deliberately awkward: a citation of a Bates number in the body text, a page numbered in a different series, a document break that lands on a page boundary, an exhibit label that reads like a stamp. Those are the shapes that produce false positives in every checker we have seen.

Withdrawn checks

Two checks were withdrawn rather than shipped: in both cases the rule was correct and the PDF reader could not see the thing it was judging. The fix belonged in the extractor, not in the rule. A check that cannot see its own defect is not a check, it is a coin toss with a citation.

What the certificate attests

  • The exact list of checks that ran, by name.
  • The checks that did not run, and why - usually because a protocol value was not supplied, or the file could not be read.
  • A SHA-256 hash of every file, taken before the check and again after it, so the certificate is tied to the bytes that were actually read.
  • The time the check completed and the engine version that ran it.

What it does not attest

It does not attest that the production is responsive, complete, or compliant with a court's local rules. It does not read privilege. It checks internal consistency: whether the set agrees with itself, and whether the load file agrees with the pages. Saying so on the certificate is what makes the rest of it usable in front of a partner.

Frequently asked questions

Can I see the test files?

The fixtures are synthetic productions built to contain a specific defect, and they are not published. A sample report from a synthetic set is at /samples, and the rule catalogue at /checks is generated from the engine.

What happens when a rule is wrong?

It is withdrawn from the run rather than left in place, the certificate lists the checks that ran, and the rule is rebuilt against a fixture that reproduces the false positive.

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 The production checklist, in the order you work Most production failures are made before the set is checked: a folder numbered in the wrong order, a load file generated before the last two documents were added, a redaction marked and never applied. This is the sequence, with the check that catches each failure at the point it can still be fixed cheaply. tool See a sample production audit The fastest way to judge this product is to read its output. The sample is a small, deliberately defective production - five files, 26 pages, ten defects planted in it - audited end to end. Download the report, the deficiency report, the findings CSV, the manifest and the certificate, and check that the certificate's hash matches the manifest you just downloaded. It is labelled synthetic everywhere it could be mistaken for a real matter, because it is not one. tool Check a PDF for production defects Upload one PDF and get a plain-language result for each production check: text layer, Bates gaps, duplicate Bates numbers, extractable stamp text, page size and rotation drift, redaction leakage, and whether the file opens at all. No account or email address is needed, and the uploaded file is checked in a temporary directory and discarded. guide Why Bates numbers land in the wrong order across files When you number a folder of PDFs in one pass, the numbering follows the order the files were added, which is usually alphabetical by filename - and neither the filename order nor the file-modified order is the order a production is served in. The sequence is still continuous, so nothing looks wrong until a receiving party reads the set. The check that catches it compares the Bates range of each file against the order the files are meant to appear. guide Why Bates numbers show up in keyword search A stamp is either an image drawn on the page or text added to the content stream. When it is text, it stays in the text layer, and every keyword search for that number or for a stray date inside it returns the page. Receiving parties use stamped numbers as identifiers, so a searchable stamp quietly pollutes their results - and in the worst case leaks a number into a privilege log as if it were document content.