How to review a colleague’s regulatory draft

Someone hands you a draft — a labeling change, a response letter, a rationale — and asks you to take a look. The fastest way to answer is “looks good.” The most common way that answer turns out to be wrong is that nobody actually checked whether the document’s claims were true, only whether it read smoothly.

What you’re actually being asked to check

A review is not proofreading with extra steps. The wording can be clean and the document can still be wrong, so check the thing proofreading misses: does every claim trace to something that is actually in front of you — a test report, a cited standard, a predicate, a regulation — rather than something you or the author are confident exists somewhere. And does the document agree with itself: the device description in section two matches the one in section five, the dates line up, the indications for use match the labeling claims. This is the same instinct behind a formal submission readiness review, just applied earlier and to smaller things — a single letter or a single section, not the whole file, and usually with no scheduled meeting at all.

How to sequence the read

Read the draft once straight through for the argument: does it make its case, and would a stranger follow the logic without you filling in gaps out loud. Read it a second time for traceability and consistency, checking specific claims against their sources and specific facts against each other. Save wording and formatting for last, after you know the content is right — polishing a sentence that gets cut in the next revision wastes both your time and the author’s. Reviewers who do all three at once tend to fix commas in paragraph one and never make it, with the same attention, to the traceability problem in paragraph nine.

Write comments the author can act on without guessing what you meant. “Unclear” by itself just returns the problem to its author with your name attached; say what is missing, or what the mismatch is, or point at the specific line it contradicts. And say plainly which comments are must-fix and which are your preference, so the author is not left defending a comma choice with the same seriousness as a mismatched device description.

Reviewing well is a skill you build by doing it, the same way asking for a useful review is a skill on the other side of the same exchange. Whatever a review turns up is worth keeping somewhere after the draft is fixed — a line in a decision log takes a minute and saves you from re-deriving the same judgment call the next time someone asks how the document ended up the way it did.