What happens to a claim Diagram

The short answer

• The reviewer's verdict is ignored
• Opus checks the most serious claims and refuted ones are dropped
• The ranker scores the rest by how often that kind of finding has been real

Not shown here

• The router and tests, which only decide whether the project's tests run, and the hooks, which only carry the result
• Connected but out of scope: Hook entry, Turn log and jobs, Settings, Router, Project tests, polywatch CLI

Doctrine

• The reviewer's overall verdict is ignored: on 50 BaanBaan commits it rejected 24 of 25 later-fixed and 25 of 25 clean ones; a score built on it separated them no better than chance (AUC 0.48)

What happens to a claim

Out of everything the reviewer says, what reaches the user and what reaches Claude?

A cheap reviewer says a lot, and most of it is not worth a person's time. On real history its verdict carried no information at all, yet its specific claims sometimes named the exact bug a later commit fixed. The pipeline exists to keep those claims and drop the rest.

The long read

The worker runs the whole pipeline, in four phases. (Before them, the router labels the change EASY, MEDIUM or HARD; the label decides only whether the project's tests run, and no longer changes how findings are judged.)

The worker then sends the changed files to DeepSeek Flash. Flash returns a verdict and a list of issues. The verdict is stored but not used: in a replay of 50 commits it rejected almost everything, buggy or not. The issues are what matter.

The worker sorts the issues by severity and sends the top high and medium ones, up to two, to Claude Opus 5.5, one claim at a time, with the cited code. Opus answers yes, no or uncertain. A no removes the claim. A yes turns it into a confirmed finding and attaches Opus's evidence. Spending stops at the per-turn budget in the settings.

The ranker then scores what is left. Each finding falls into one of six kinds (confirmed or not, by severity), and each kind has a precision: a starting guess, moved by every outcome in the ledger. Findings below 0.25 are hidden. Delivery takes the top two, shows them to the user, and sends only the confirmed ones to Claude, for at most two turns in a row.

Terms used here

turn: One round of Claude Code work: the user's prompt and everything Claude does in answer, up to when it stops.
hook: A command Claude Code runs at a fixed event, such as after a file edit, when a turn stops, or when the user submits a prompt.
tier: polywatch's label for how hard a change is to get right, from its size and whether it touches concurrency, state or protocol logic.
claim: One specific, checkable statement a reviewer makes about a defect: which file, where, and what is wrong.
finding: A claim that survived confirmation (it was not refuted), with a score. Confirmed findings carry Opus's evidence.
confirmed: Opus checked the claim against the code and said it holds.
refuted: Opus checked the claim against the code and said it does not hold. Refuted claims are never shown.
precision: The share of findings of one kind that turned out to be real bugs, as estimated from recorded outcomes.
ledger: An append-only file of every review and every outcome, used to calibrate the ranking.
outcome: The user's verdict on one finding after the fact: real bug or false alarm.