BASALT · JOURNAL
Redacting documents for a public records release
A public records release is not one redaction decision repeated. It is a set of decisions that must agree with each other across thousands of pages produced by different people at different times. Teams that redact documents for FOIA and similar requests usually get the individual marks right and get caught by inconsistency, where a name withheld on page 40 sits intact in an email header on page 812. This article covers process and file mechanics, and it is not legal advice.
What gets withheld, and where it hides in a records set
The categories vary by jurisdiction, but the shapes recur.
Personal identifying information about third parties. Home addresses, personal phone numbers and email addresses, dates of birth, and identification numbers belonging to people who are not the subject of the request. These are dense in email traffic, where signature blocks repeat on every message.
Names of individuals with a privacy interest. However that balance falls in your jurisdiction, once a name is withheld it must be withheld everywhere, including in the From and To lines of forwarded messages, in attachment file names, and in the metadata of the produced PDF.
Deliberative and pre-decisional material. Draft language, internal recommendations, and comments. Drafts arrive as tracked changes and as PDF annotations, and a comment holds its text in an object separate from the page.
Attorney-client and work product material. Frequently entangled with ordinary correspondence in the same thread, which makes partial-page redaction the norm.
Security-sensitive operational detail. Building access information, system configuration, credentials pasted into an email body, and network diagrams embedded as images.
Commercial information submitted by third parties. Pricing tables, unit costs, and terms, usually in attached spreadsheets and often reachable inside the PDF as an embedded file.
Where these hide is the familiar list: the content stream under a drawn box, the OCR layer under a scanned page, annotations, form field values, attachments, optional content groups, metadata, and earlier revisions retained by an incremental save. Hidden data in PDFs covers each carrier.
Exemptions are cited per redaction, not per document
The defining feature of a public records release is that each withholding is attributable. A requester and a reviewing body should be able to look at a black mark and know which basis was claimed for it.
That means the reason has to be attached to the mark when the mark is made, not reconstructed later from memory. Reconstruction is where errors enter: a mark made for one reason gets logged under another, two similar marks get different labels, and the log contradicts itself in ways that invite challenge.
A generic statement that the release contains exempt material of several kinds is not the unit of accountability. The individual mark is. Practically, your marking tool needs to record a reason per mark and export from those reasons, the same mechanism as a privilege log built from redactions.
Consistency across the set is the hard part
Any competent reviewer can redact one document. The failure mode in a release is one value handled differently in two places.
There are three flavors. The first is a missed instance: a name redacted on the pages you read closely and left intact in a running header, a table, or an email quoted five replies deep. The second is category drift: a phone number withheld in the first hundred pages and released in the next hundred, because a different reviewer took a different view. The third is cross-document inference: a name withheld in one document and inferable in another from a title, an office, and a date, which survives review most often.
The countermeasures are procedural. Maintain one shared value list and treat it as the authority. Search for each value across every document rather than reviewing page by page. Have one person own the category decisions so drift does not enter through parallel reviewers. Then verify the whole set against the list at the end, as a mechanical check rather than a reading.
How to redact documents for FOIA across a set
Assemble and inspect first. Get the full set in hand, then inspect it for attachments, annotations, hidden layers, OCR layers, form fields, and metadata before anyone marks. See inspecting what a PDF contains.
Build the value list. Every name, address, phone number, email address, and identifier to be withheld, with formatting variants. Add to it as review proceeds, and re-run earlier documents against additions rather than assuming they are clean.
Mark with a reason attached. Marks without a recorded basis are ones you will defend from memory.
Search and redact each value document-wide. This is the mechanism that produces consistency: visual review finds what you read, and search finds what is there.
Handle images and scans. Faxed and scanned pages need the pixels destroyed and the underlying OCR text destroyed with them, and signatures, badge photographs, and diagrams need the same.
Produce the log from the marks, rather than writing it separately, so the log and the document cannot disagree.
Verify the set, then release. Extract text from every produced file and search for every value on the list. A single hit anywhere fails the whole set.
Frequently asked questions
How do I redact documents for a FOIA request?
Assemble the full set first, inspect every file for attachments, annotations, hidden layers, OCR text, and metadata, then build one shared list of the values to be withheld. Record the basis on each mark, apply each value across the whole set by search rather than reviewing page by page, and verify the finished files by extracting text before release.
Do I have to cite an exemption for each redaction?
Public records practice generally treats each withholding as separately justified, so the basis is attached to the individual mark rather than asserted once for the document, which lets a requester or a reviewing body evaluate a specific mark. Record the reason when the mark is made, since reconstructing reasons afterward is where inconsistencies enter. Your obligations are a matter for counsel.
How do I keep redactions consistent across a large release?
Maintain a single value list for the whole release and apply each value by document-wide search rather than by reading, then verify every produced file against that list at the end. Assign category decisions to one owner so parallel reviewers do not diverge on what counts as withholdable. When a value is added mid-review, re-run the documents you already finished.
What is a redaction log and what goes in it?
A redaction log is a record of what was withheld and on what basis, generally listing the document, the location, the nature of the material, and the ground claimed. Its value depends on being generated from the marks themselves rather than compiled separately, because a hand-written log drifts from the document it describes. See building a privilege log from redactions.
Does a black box satisfy a public records redaction?
Not on its own. A black box drawn over text is a drawing instruction added above the page, and the characters underneath remain in the content stream where any extraction tool reads them. Released files are downloaded, indexed, and parsed as a matter of routine, so a covered-but-present name is found quickly. The content has to be removed from the file.
How do I redact scanned records for a release?
Redact the pixels and the OCR text layer together. Scanned and faxed records that have been through OCR carry invisible positioned text under the image, and destroying the pixels while leaving that layer produces a page that looks redacted and extracts perfectly. Verify by extracting text from the finished file.
Should I remove metadata before releasing records?
Yes, as a routine step. Metadata and the XMP packet commonly carry the author account name, the producing application, timestamps, and the original file path, and such a path discloses information the page does not. Metadata survives page-level redaction, so it has to be stripped explicitly when the file is written.
What is the most common mistake in a records release?
The most common mistake is inconsistency: a value properly withheld in most of the set and left intact somewhere nobody read, usually a running header, a quoted email thread, an attachment, or a metadata field. It is a search problem rather than a judgment problem, which is why mechanical verification catches it and careful reading does not.
Doing it in Basalt
Basalt is built around the two things that make a release survive scrutiny, consistency and evidence: search and redact finds every instance of a value across a document, so a name withheld once is withheld everywhere, and the Inspector reports what each file still carries before you begin. Every mark records a reason, including privilege, PII, work product, HIPAA, and confidential, and a log exports to CSV and XLSX generated from those marks rather than written by hand, so the log and the document cannot drift apart. Redaction destroys content: glyphs excised from the content stream, image pixels destroyed and re-encoded, OCR text under a mark destroyed, and metadata, attachments, and hidden layers stripped as the file is written in one generation. A verifier re-opens the written file with an independent parser and proves the content is gone before anything is saved, and the engine has no network entitlement, enforced by macOS at the code signature level, so records never leave the machine. It is $29 once, lifetime, up to three Macs, free for 24 hours; see also the checklist before filing and redacting medical records.
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.