PDF Rescue

Some PDFs need a little help:

• text that won't copy cleanly
• tables that come out scrambled
• a reading order that jumps around

PDF Rescue turns a badly formatted PDF into a nicer, cleaner copy, without quietly changing what the document says.

• It leaves the original alone.
• It makes a companion copy and explains what changed.
• When it can't do something safely, it says no instead of guessing.

Read how it was built ↓

What we wanted

"that's what i meant it extracts content then something else reorganizes it"

"how easy would it be for it to handle tons of pdfs online"

Steve

I wanted to know if a messy PDF could be pulled apart and rebuilt into something nicer, without needing the PDF Workbench editor. It was a new experiment, not a rewrite of the old tool.

Planning before building

Faye suggested treating it like document conservation, the way a museum handles an old letter:

• keep the original
• make a companion copy
• explain every change
• decline anything that can't be done safely

Chad, the crew’s coordinator, packed that into a 19-file research kit.

Five specialists then looked at the hardest kinds of PDF: forms, reports, tables, scans, and files built to cause trouble. When four ran at once, the provider pushed back with a rate limit, so the rest ran three at a time.

Next, Composer ran a proper investigation in three waves of five seats. MiMo hunted for contradictions and tricky scenarios, DeepSeek worked on the architecture, and SWE planned the implementation. All 15 seats finished. Their joint answer: before building, write down what "correct" means and make test files that prove it.

How the build unfolded

So the crew froze a set of test PDFs, a written protocol, and checks run by someone other than the builder. Then the build was handed to its planned builder.

The snag, and the repair

The planned builder didn't deliver. Six big requests across two attempts came back marked successful, with nothing inside. A "success" response isn't a finished file. Chad built the first working slice directly from the frozen plan instead.

Then came the checks. The builder used one set of PDF tools, and the checkers used completely different ones, so a mistake in one toolkit wouldn't be graded by that same toolkit. They caught all six planted corruptions.

The Boss Battle

Later, the crew set PDF Rescue a harder test:

1. One agent built a deliberately difficult synthetic PDF.
2. A second agent rebuilt it, seeing only the public challenge and never the judge's answer key.
3. A third agent judged the result.
4. A fourth wrote up what everyone learned.

Each stage ran once, with no retries. The score was 100 out of 100: every text block, every table cell and every reading-order pair came out right, and the rebuild was identical when run again.

It wasn't perfect outside the scored checks:

• screen-reader behavior was not tested
• one extraction mode mixed up two columns
• a rotated note ended up facing a different way

It was one synthetic test, not a benchmark against real-world files.

What you can do with it now

PDF Rescue is a working local prototype that held up on synthetic test files. The next step is real PDFs from the web.

• Planning kit: 19 files, prepared by Chad from Faye’s conservation approach.
• Specialist investigation: five GLM 5.3 FlashX specialties.
  • About 13 min 51 s elapsed; about 29 min 30 s of worker time added together.
  • 91 provider responses; 230,190 tokens reported.
  • One four-at-once attempt hit a rate limit (HTTP 429); the rest ran capped at three.
  • Five specialties did not mean five successful simultaneous requests.
• Composer investigation: 28 min 52 s (Sept 29, 2026, 11:50:03–12:18:55 UTC).
  • 3 waves × 5 seats = 15 completed, with no model swapped in.
  • MiMo: scenarios and contradictions. DeepSeek: architecture. SWE: implementation planning.
• First build: the planned GLM 5.3 FlashX builder returned empty answers on six calls across two attempts, each marked successful. Chad wrote the first local slice from the agreed plan after the assigned builder returned empty answers.
• Tools: built with pypdf and reportlab; checked with pdfminer, pdfplumber, Poppler and Pillow.
• Results on 8 synthetic PDFs (19 pages):
  • source hashes preserved
  • byte-identical rebuilds
  • 6 of 6 planted corruptions detected
  • 1 visible defect fixed (a double space, one to zero), 7 files visually unchanged

• Boss Battle: 39 min 7 s (Sept 29, 18:52:16–19:31:23 UTC). 100/100 on its declared checks:

  • 21/21 semantic blocks
  • 65/65 table cells
  • 21/21 reading-order pairs, in both default and raw extraction
  • no contamination
  • byte-identical rebuilds

  Full details are on the Boss Battles page. It's the same battle, so count it once.

• Not recorded: full idea-to-today time, active working time, and cost. These runs are separate, so adding them up would not give the build time.