everyday mac tools

A privilege log built from the redactions themselves

· 6 min read

A privilege log is a list of what you withheld and why. If you type it up in a separate document from the file you redacted, the two drift: a mark gets added on the last pass, a page is renumbered, a document is split, and now the log describes something that no longer exists. Building each row from the mark that removed the content is what stops that.

This post is about the mechanics of keeping the log and the file in step on a Mac. The legal requirements come from the rule, order or agreement you are working under, and they vary; what follows is the shape of the work, not advice about what your log must contain.

What a row usually has to carry

Most logs, whatever the jurisdiction, want the same kinds of column:

  • an identifier that points at a fixed place in the production, normally a Bates number or range
  • the date of the document
  • the author, and the recipients
  • the type of document (letter, memo, email, attachment)
  • the basis claimed for withholding
  • a description that says enough to let the other side test the claim without disclosing the thing you withheld

The last two are judgment. Everything above them is data that already exists, which is why it should not be retyped.

Why the hand-typed log drifts

Four failure modes, all common, none dramatic.

Page numbers move. A log that says “page 12” is correct until the set is split, merged or re-ordered. After that it points at a different page and nothing in the file objects.

Late marks never get a row. The review is done, someone spots one more name on a second read, marks it, and does not go back to the spreadsheet. The document ships with an unlogged redaction.

Two people work on the same set. Both keep a log, the two are merged by hand at the end, and the merge is the least careful part of the process.

The log is written afterwards. Reconstructing a week of decisions from a stack of black boxes produces descriptions that are vaguer than the decisions were, and occasionally wrong about which rule was being relied on.

Anchor to Bates numbers, not page numbers

Number the set before you redact. A Bates number is a permanent address printed on the page, so a row that says CO-004871 keeps meaning the same thing after the set is split, re-ordered or produced in batches. Bates numbering on a Mac covers how to apply them.

If you number after redacting and then have to re-run the redaction pass, the numbers can shift and every row in the log becomes suspect. Number first.

Record the reason at the moment you make the mark

Agree a short, fixed set of reason codes before the review starts and do not add to it halfway through. Something like AC for attorney-client, WP for work product, PII for personal data, TP for third party confidential, whatever the matter actually needs. Six codes that everyone uses the same way beat twenty that each reviewer interprets.

Then write the code as you draw the mark, not at the end of the day. A code chosen at the moment of the decision is a record of that decision. A code assigned a week later is a reconstruction, and reconstructions are what get taken apart when the log is challenged.

Building it on a Mac

With macOS on its own, the log is a spreadsheet and the discipline is the whole method. Numbers or any spreadsheet app will do:

  1. Fix the columns before the first mark: Bates, date, author, recipients, type, basis, description, reviewer, and the date of review.
  2. Keep the file in the same folder as the production, not in someone’s home folder.
  3. Add the row when you make the mark. One row per withheld item, in Bates order.
  4. Use Preview’s Redact tool for the marks themselves, and reopen and check each saved file before moving on. Redacting a PDF in Preview covers the tool and its limits.
  5. Export the finished sheet as CSV as well as keeping the working file, because CSV is the version you can diff and sort from Terminal.

That works. It relies entirely on nobody skipping step three under time pressure, which is the thing that always happens on the last afternoon.

The alternative is to have the log come out of the marks rather than beside them. Basalt has a Privilege Log tool that writes CSV and XLSX straight from the marks in the document, so the identifier and the location on the page come from the same objects that removed the content. Its exports are reproducible from the marks, which means running the same marks on the same file again gives an identical export and an identical log.

What no tool can do is decide the basis. Whether a passage is privileged, and how to describe it without giving it away, is your judgment and it has to be recorded by you. A log generated from marks is accurate about where and what; it is only as good as you are about why.

Check the log against the production

Do this on the produced files, not the working copies.

  1. Count. Number of marks in the set against number of rows in the log. A mismatch is a missing row or a mark you forgot you made.
  2. Resolve every identifier. Every Bates number in the log exists in the produced set, and lands on a page with a visible mark.
  3. Walk the other way. Page through the export looking for black. Every mark you find has a row.
  4. Read the descriptions cold. Hand them to someone who has not seen the documents and ask whether any of them discloses what it is supposed to protect. Descriptions written at speed sometimes name the thing.
  5. Check consistency. The same document withheld in two places gets the same basis. Different bases on the same document is the first thing anyone reviewing the log will find.
  6. Verify the files themselves. A log is a claim about a set of documents; it is worth nothing if the redactions in those documents did not take. How to check whether a PDF was really redacted is the routine, and Preparing a document production on a Mac puts it in order with everything else.

Questions

Do I log redactions inside produced documents, or only documents withheld in full? That depends on the rule or the agreement, and practice differs. Settle it in advance with the other side rather than discovering the expectation later, and whichever answer you get, apply it consistently across the whole set.

Should the log be produced as a PDF or a spreadsheet? Keep the spreadsheet whatever you produce. CSV and XLSX can be sorted, counted and compared against the file set; a PDF of the log cannot, and you will want to compare it more than once. Produce a PDF version if it is asked for, generated from the sheet rather than maintained separately.

A mark changed after I exported the log. What now? Re-export the whole log. Editing one side by hand to match the other is how the two versions start to diverge.

How much detail belongs in the description? Enough that the claim can be tested, not enough to disclose the content. Describing the document (its date, type, who wrote it to whom, and the general subject) rather than what it says is the usual line. When in doubt, write it and then read it back as if you were the person trying to work out what was removed.