BASALT · JOURNAL
Running the same PDF steps over and over without doing them by hand
You have forty documents and each needs the same five operations in the same order. Doing that by hand is not slow so much as unreliable: somewhere around document twenty-three you will apply step four before step three and not notice. The fix is to describe the sequence once and run it.
Repetition is a correctness problem, not a speed problem
The obvious argument for automation is time. The better one is that a human performing a five-step sequence forty times produces forty slightly different results.
Steps get reordered. A parameter gets typed differently on one file. One document gets six steps because someone was interrupted mid-sequence. None are dramatic mistakes and all are invisible in the output, which is what makes them dangerous. A production where three files were numbered from a different starting value looks fine until someone tries to cite a page.
A saved sequence removes that variance by construction. The same steps run in the same order with the same parameters, and what was done is something you read rather than remember.
What belongs in a saved procedure
Anything you have done twice the same way, and specifically anything where order matters.
A production pipeline is the obvious case: stamp identifiers, apply redactions, verify, export a log. Numbering before redaction is what makes a privilege log consistent with the file by construction, an argument developed in reproducible redaction. A procedure encodes the ordering so it cannot drift.
Intake normalization is another: OCR anything without a text layer, strip metadata, flatten annotations, compress. Each is a judgment call once and mechanical after.
Automation has to be constrained, not just capable
This is where most automation stories go wrong. A tool powerful enough to run five operations unattended can run a destructive one unattended, and the two capabilities arrive together unless someone separates them.
No irreversible action without a person. Applying a redaction destroys content by design, and no automated pass should do that without someone looking. A script can reasonably propose where marks belong by searching for patterns like account numbers, and a human decides. The proposal is the useful part; the application needs judgment.
No network. Document processing needs no network access: every operation described here reads and writes bytes on a local disk. Automation that can also open a socket can exfiltrate a document, by design, by bug, or because someone pasted in a script they did not read.
That second point deserves precision. On macOS a process's entitlements are part of its code signature and checked by the system, so a process without the network entitlement cannot make outbound connections, and no scripting inside it changes that. Configuration is a preference; a missing entitlement is a property of the binary. That is what makes automation acceptable on documents covered by an obligation you signed, as in redaction for law firms.
What macOS gives you and where it stops
Automator and Shortcuts can chain PDF actions, and for simple work they are fine. Their limits show up quickly: the built-in actions cover assembly and rendering rather than redaction, comparison, or numbering, and cannot express a parameter varying with page geometry.
The command line is more capable. A shell script driving qpdf for structural operations and pdftk-java for stamping does a great deal, and Python with pypdf covers the rest. In exchange you own a script that will eventually meet a page whose CropBox differs from its MediaBox, a /Rotate 90 scan, or an object stream your library mishandles.
There is also what those tools do to parts of the file you were not thinking about. Many rewrite the document wholesale, dropping metadata or altering annotations, the subject of hidden data in PDFs.
Every step should write a new file
The single most useful property in a repeatable pipeline is that no step modifies its input.
When each operation reads one file and writes another, a mistake at step four costs you steps four and five, not the source document. You can re-run from any point, and diff any intermediate against the original to see what a step did. In-place modification breaks all of that, and it breaks worst in the situation automation is for: a batch that fails partway, leaving you unsure which files changed.
Verify the batch, not a sample
Running a sequence forty times identically means any error in it occurred forty times identically.
That is easier to catch than forty different errors, but only if you check, and the check should be mechanical and cover every output: extract each page's Bates number and assert the sequence is gapless, search every file for the strings you redacted and assert zero hits, confirm page counts. Spot checking three files out of forty is how a systematic error reaches a recipient, as argued in verifying a PDF redaction.
Frequently asked questions
How do I batch process PDF files on a Mac?
Use an application that saves a sequence of steps and replays it, or write a script around command line tools such as qpdf and pdftk-java. Automator and Shortcuts chain the built-in PDF actions for simple assembly, but do not cover redaction, comparison, or numbering, and cannot express parameters that vary with page geometry.
Can Automator batch process PDFs?
Automator can chain the PDF actions macOS ships, which cover combining, splitting, applying Quartz filters, and rendering to images. It cannot redact, compare documents, apply Bates numbering, or run OCR, and offers no control over per page geometry. For simple assembly it works; for anything that must be correct across a mixed document set it does not.
Is it safe to automate redaction?
Automating the search is safe and automating the removal is not. A script can reasonably propose where marks belong by looking for patterns such as account numbers, which saves real time on a long document. The decision to destroy content should stay with a person, since a false negative ships what you meant to withhold.
What is the difference between a procedure and a script?
A procedure is a saved sequence of the application's own operations with their parameters recorded, so it replays exactly what you configured by hand. A script is code expressing logic the interface does not offer, such as conditional steps or pattern searching. Procedures are safer because their vocabulary is limited to actions you understand.
Will batch processing modify my original files?
It depends on the tool, and it is worth checking before you run anything across forty documents. A pipeline where every step writes a new file leaves your source untouched, so a mistake at step four costs only steps four and five. In-place modification is worst when a batch fails partway.
How do I check that a batch ran correctly?
Run a mechanical check over every output rather than spot checking a sample, because a systematic error in the sequence occurred identically on every file. Extract each page's number and assert the sequence is gapless, search every output for the text you removed and assert zero hits, then confirm page counts.
Can automated PDF tools send my documents somewhere?
Only if the process running them has network access, which document processing never needs. Every operation involved reads and writes bytes on a local disk, so the right posture is a process with no network capability, enforced by the operating system rather than trusted to the script.
What order should PDF operations run in?
Stamp identifiers first, then apply redactions, then verify, then export any log, because a privilege log referencing page numbers is only consistent with the file if the numbers were there when the marks were placed. Signing goes last, since any later change breaks it. A procedure stops that ordering drifting.
Doing it in Basalt
Basalt's PROCEDURES tool saves a sequence of steps so the same steps run the same way every time, and its SCRIPTS tool covers cases a fixed sequence cannot express. Both run inside the same sealed engine process, which holds no network entitlement, enforced by macOS at the code-signature level, so a script can propose redaction marks but can never apply them without you and can never phone home. Every tool writes a new file, so nothing modifies your original. They sit alongside 16 other tools including redact, compare, and Bates numbering, for $29 once across three Macs, free for 24 hours, at basaltformac.com.
Redaction that proves itself
Basalt destroys the content you mark, then re-opens the file it wrote and proves the content is gone before it saves anything. Your documents never leave your Mac.