BASALT · JOURNAL

How to run a two-person redaction review

2026-09-21 · two person redaction review

Two people looking at the same page is not automatically two-person control. A useful maker-checker process gives the second reviewer independent evidence and the authority to stop release.

Divide the roles clearly

The maker interprets the approved instructions, marks the document, assigns reasons, and completes the first visual review. The checker does not simply watch the maker's screen. They receive the source inventory, instruction version, search-value list, mark log, and proposed release file.

The checker should be able to answer three questions independently: did the maker cover the approved scope, is each redaction technically irreversible, and did unrelated content survive?

Give the checker a review packet

A compact packet contains:

• source filenames, page counts, and hashes;
• the governing instruction or codebook version;
• known identifiers and search variants;
• a mark-level log with page and reason;
• the verifier report for the release candidate; and
• any exceptions, uncertain calls, or rasterized pages.

Do not include the secret text in an ordinary release log. If reviewers need a value map, keep it in a separate restricted location.

Review in a different order

The checker should search the target list directly, inspect repeated page furniture, and review high-risk structures such as scans, images, attachments, metadata, and form fields. Reading some pages in reverse order reduces the tendency to follow the narrative and miss visual details.

For very large sets, define the sampling rule before seeing results. Always review pages with redactions, plus all exceptions and a random share of unmarked pages. A single critical failure should expand the sample or return the batch to the maker.

Control disagreements and release

Record disagreements as open items rather than resolving them in chat or by silently changing a mark. The authorized decision-maker closes each item. After the final edit, regenerate the output and verifier report; approval of an earlier file does not approve a later one.

Only the checker or release owner should move the approved hash into the outbound location. Preserving the original during redaction keeps source and release copies from being confused.