Building a review checklist

In plain English

A review checklist is a short list of checks you run every time before you accept generated code or content, so you do not rely on memory. A sign-off is a yes-or-no decision recorded by a person who takes responsibility for the result. Logging decisions means writing down what you accepted, why, and what evidence you saw, so you can explain it later. A useful checklist covers correctness, security, privacy, licensing and whether the work actually matches the requirement. When any check fails, you either fix the output or reject it, and you record that outcome too.

Step by step

1. 1Write down the five checks that matter for your project.
2. 2Run each item on a piece of generated work and tick it off.
3. 3Ask a second person to review anything security- or customer-facing.
4. 4Record the decision, the reviewer and the evidence in one place.
5. 5Re-run the checklist whenever the generated work changes.

- [ ] Runs and passes tests, including one new edge case
- [ ] No secrets, extra permissions or unsafe inputs
- [ ] No personal data in logs or responses
- [ ] License can be complied with
- [ ] Matches the requirement, with nothing extra added

Sign-off: ______  Reviewer: ______  Date: ______
Decision log: what was accepted, why, and the evidence seen.

Common mistakes

• Reviewing without a list makes you miss the same step every time under deadline pressure.
• Signing off without reading the diff passes responsibility without taking it.
• Not logging decisions means you cannot reconstruct why a change was accepted months later.
• Checking only whether code runs ignores security, privacy and licensing, which is where real harm hides.