BUILD RECORD
aiPDF Engine
A document job became a sequence of retryable steps, so one bad page did not take down the whole run.
PRODUCT BUILD
A long document job can die on one bad page, hours in.
One job per step, with retries behind each.
aiPDF Engine
Retired
A serverless pipeline for large document sets. A router took the upload and the request, a planner ordered the jobs, and a queue carried them.
A long job survived its worst page: one bad scan retried on its own instead of killing the run.
Whole documents split into jobs rather than one prompt per file. Three workers, one job each.
FastAPI planner queue dead-letter queue
Architecture, planner, workers, infrastructure, open-source release.
Open source, built and released solo. One file deployed the whole stack. It ran end to end against a local AWS stand-in.
THE METHOD
How one request ran, start to finish
A typical request: "Clean up this scanned packet."
a document request · upload to specialist
took · planned · queued · ran
A FastAPI router caught both.
It planned which workers ran, and in what order.
One job ran per step and retried on its own if it failed.
It split, merged, and rotated the documents, ran OCR, then compressed and repaired them.
LIMITS STAY ATTACHED
What it refused to do
The planner only ordered operations the workers implemented.
A job that kept failing landed in a dead-letter queue.
Quotas were tracked, so one job could not hog the queue.
RECORD AND LINEAGE
Where it went
PagePurger, the same pipeline pointed at medical-legal record review.
Let the model order the jobs. Split, OCR, and compress stay code.
THE ARCHITECTURE
A RELATED PROBLEM
Does one bad page still break a long document job?
This build is retired, but durable document work is still hard. If the failure boundary is costing you time, I would like to see it.