BASALT · JOURNAL
A PDF redaction quality-control workflow that catches real failures
Good redaction QA tests two opposite claims: everything approved for removal is gone, and everything approved for release is still intact. Checking only the first can silently damage evidence; checking only the page image can miss recoverable content.
Gate 1: scope and inventory
Before editing, identify every source file, page count, file hash, governing instruction, and expected output. Build the search list with variants and assign a reason code to each category. A missing file cannot be rescued by perfect redaction inside the files you did receive.
Gate 2: maker review
The maker searches known values across the whole document and visually reviews every page. Scans get OCR as a discovery aid, followed by inspection for handwriting, barcodes, faces, and text inside images. Repeating headers and footers get a separate pass.
Marks remain reviewable until the maker completes the list. Applying them too early makes adjustments harder and encourages confirmation bias: once a bar looks final, people stop questioning its boundaries.
Gate 3: destructive apply and sanitization
Apply redactions to a new file. Remove metadata, XMP, annotations, form values, attachments, JavaScript, hidden layers, stale thumbnails, and prior revisions. A page can be perfectly redacted while the original survives as an attachment or earlier incremental update.
Gate 4: independent verification
Use a parser other than the writer to extract text and inspect the output structures. Search every target string, inspect pixels under image marks, and confirm there is one clean generation. Also compare unmarked neighboring text and page counts with the approved source.
The check must run on the exact release candidate, not a temporary file that is later combined, compressed, or uploaded. Any later transformation creates a new artifact and requires another check.
Gate 5: checker review and release
The checker reconciles marks against the reason log, samples or fully reviews pages according to risk, and confirms naming, sequence, Bates ranges, and destination. Record the final file hash, verifier result, reviewer, time, and instruction version. Keep the unredacted source segregated from the release folder.
For the human handoff, see two-person redaction review. For technical tests, see how to verify a PDF redaction.
Frequently asked questions
What is the most important redaction QA step?
Independent verification of the exact release file. It tests the written artifact instead of trusting the state held by the editor that produced it.
Should QA check content that was not redacted?
Yes. Page count, surrounding text, layout, and key totals or references must remain intact; excessive removal can be as consequential as a leak.
Does a second reviewer need to read every page?
That depends on risk and procedure. High-impact public or legal releases often justify full review; lower-risk batches may use targeted and random sampling backed by automated checks.
Doing it in Basalt
Basalt separates marking from irreversible application, runs preflight and post-export verification, and refuses to save an output it cannot prove. Certificates, hashes, reason codes, Bates manifests, and privilege logs make the release record reproducible. The engine operates without network access. Learn more.
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.