Skip to main content
Yes. A model reading its own family’s work tends to approve its own habits, so the reviewer should come from a different family, and the check should be the runtime’s, not a review you have to remember to do. In a workflow(), each engine declares its provider and model family, and a team whose reviewer shares the writer’s family is refused when the team is built. Before the reviewers run, the runtime checks again on the recorded answers: the family the writer’s engine reported must differ from each reviewer’s, and an answer whose family can’t be read fails the panel too. A model’s accept is still not a person shipping the change.

​
In Obversa

The writer is a Claude seat and the reviewer is a Codex seat, and the review stage names where a rejection goes:
examples/teams/writer-reviewer-pair.ts (excerpt)
The reviewer reads the code, the test and its result, and a rejection puts its findings in front of write, which runs again with them. In a graph form, the review loop’s requireDiversity asks for the same thing across its review seats.

​
Review panel

One reviewer is a second opinion. Several reviewers with a threshold are a panel, and How many reviewers have to accept? says how the count works.

​
Next steps