What should a content brief tell the reviewer?

A brief often explains what the writer should produce but says little about how someone will approve it. That can lead to a draft being judged against requirements nobody wrote down.

My example brief would start with the reader's question and the answer the page must make clear. Then it would list necessary sources, examples, relevant internal links, claims needing verification, and the person responsible for review.

I would also include an “out of scope” box. A beginner guide does not need to become a complete reference manual to be useful.

What belongs in the review criteria, and what should remain the writer's judgment?

Make completeness concrete. Instead of “cover the topic thoroughly,” ask whether the reader can perform the intended task after reading it.

The brief can identify required decisions and cautions without prescribing every heading. I would leave the structure flexible unless the page must follow a product or support template.

For technical material, include the environment assumed by the examples. Advice can be correct for one platform and unhelpful for another.

A reviewer should check that commands, configuration examples and screenshots match the stated environment. Search terminology alone is not a sufficient technical review checklist.

I would add two approval questions: are the factual claims supported, and does the example actually demonstrate the answer?

That keeps review focused. Style preferences can be discussed separately, while unsupported claims or a misleading example need correction before publication. The reviewer and writer should both know which kind of feedback is being given.