Cerebe / How it works

Independent critics. Fixed rules. One verdict per commit.

Critics from competing model vendors review each pull request in isolation. A fixed rule, not a model, turns their findings into one verdict. It is signed, bound to the commit, and posted as a GitHub check.

Pull request every commit ISOLATED · NO WEB ACCESS Critic · competing vendor sees the change and the repo Critic · competing vendor never sees the others' work Critic · competing vendor returns findings with evidence MODEL KEYS NEVER REACH THEM Fixed rules not a model Verdict signed, bound to the commit posts as a check required when you choose evidence behind every finding Pull request every commit ISOLATED · NO WEB ACCESS Critic · competing vendor sees the change and the repo Critic · competing vendor never sees the others' work Critic · competing vendor returns findings with evidence MODEL KEYS NEVER REACH THEM Fixed rules not a model Verdict signed, bound to the commit posts as a check required when you choose evidence behind every finding

The five stages

From pull request to check.

1 · Review in isolation

Each critic is a model from a different vendor, running in its own sandbox with no web access and no view of the other critics. It sees the change, in the context of the repository, and your repository's AGENTS.md.

2 · Findings with evidence

A critic returns findings, not a score. Each says why it matters and what the fix is, and is tied to the file and line where it has one.

3 · A verdict from fixed rules

A fixed rule, not a model, turns the findings into one verdict. The same findings under the same rules give the same verdict, every time.

4 · Signed and bound to the commit

The verdict is signed and bound to the exact commit it judged. Amend the commit and it is reviewed again; a stale verdict never covers a new change.

5 · Posted as a check

The verdict posts to the pull request as the cerebe/critic check, with the findings and their evidence. Required when you choose, on a paid plan, and then it fails closed.

What we publish

Everything you need to verify a verdict.

We publish the verdict, every finding, the policy it was judged under, and which reviewers judged it. Anyone with the CLI and read access to the repository can verify a verdict's signature and its binding to the commit.

Local and hosted

The same verdict math, on your workstation and in the check.

On your workstation, the Cerebe CLI reviews every commit, alongside Claude Code, Codex and Cursor, so problems are caught before there is a pull request. The hosted check reviews every pull request and is the approval of record. The workstation review is the author's convenience; the check is what gates merge.

See it on your own pull request.

Install the GitHub App on one repository and your next pull request gets a verdict as soon as it is opened or updated.