Zephr

Intelligence · Review

A review finding shouldname its source.

Review answers one question about a change: does it contradict something this team already decided? The answer is a query over your own reviewed evidence — the decision that forbids a pattern, the belief a change contradicts, the document an API deprecates — cited at the exact revision it was recorded. Every finding carries a proof-adequacy receipt, and when the evidence is not there, Review abstains instead of writing a paragraph.

Exact-change contracts shippedEngine evolvingManaged review planned
How it works

A finding is a query, not an opinion.

The change is resolved to exact revisions, those revisions are queried against the evidence graph, and whatever the graph returns becomes the verdict — scored for how much proof it actually had. Nothing in the pipeline generates prose about code it has no evidence for.

Exact change extraction

Shipped

The diff is resolved to exact revisions — which symbols, at which commit, on which ref. A review that is vague about what changed cannot be precise about what it broke.

Evidence query

Evolving

Each changed symbol is a query against the evidence graph: which reviewed decisions constrain it, which beliefs cite it, which documents describe it.

Deterministic verdict

Evolving

The same change against the same graph produces the same finding, every run. No sampling, no temperature, no re-roll that produces a different opinion.

Proof adequacy

Evolving

Every finding scores how much evidence actually backed it — and abstains, visibly, when the honest answer is that there was not enough.

Portable review capsule

Planned

The finding, its citations, and its receipt sealed into one signed artifact that another tool or another machine can re-verify.

ReviewBench

Planned

A deterministic, CI-blocking benchmark for review quality — the same posture TrustBench takes toward trust semantics.

The distinction

Opinion review and evidence review are different products.

LLM-opinion reviewers — the CodeRabbit-class tools — are genuinely useful: they catch things nobody wrote down, and they work on a repository with no prior context at all. Review is not that. It only knows what your team recorded, and in exchange every finding it makes is traceable to a specific reviewed record.

Comparison of LLM-opinion review and evidence-native review across five dimensions
DimensionLLM-opinion reviewEvidence-native review
Where the finding comes fromA model reading the diff and generalising from its training data.A query over decisions your team recorded and a human reviewed.
ReproducibilityRe-running produces a differently worded — sometimes differently opinionated — result.Same change, same graph, same verdict. Deterministic by construction.
CitationPoints at the lines it is commenting on.Points at the lines, and at the exact revision of the decision that governs them.
When evidence is thinProduces a confident comment anyway — the model always has an output.Records insufficient proof adequacy and abstains, on the record.
What a reviewer must doJudge whether the comment is right, with no way to check where it came from.Open the cited decision and check whether it still applies.

Where opinion review wins: a repository with no recorded decisions. Review has nothing to query and will correctly say so. The two are complementary, and this page does not pretend otherwise.

The artifact

One finding, and the receipt that backs it.

Real markup, not a screenshot: the finding, the exact-revision evidence it cites, the proof-adequacy receipt including the criterion it failed, and — on the same PR — a question Review refused to answer.

Review · findingContradicts a reviewed decision

This change contradicts a reviewed decision about session revocation.

The pull request caches session validity for sixty seconds. A decision recorded seven weeks earlier — and reviewed by a human — requires revocation to take effect within one request. Those two things cannot both be true.

Change
PR #2841 — Cache session lookups in the auth middleware
Ref
refs/pull/2841/head
Decision
Session validity is read through on every authenticated request; revocation must take effect within one request.
Recorded
2026-01-22T14:07:39Z at 31d6c0f Reviewed by a human on 2026-01-23

Cited evidence

  • Decision decision:7f21c8 @ 31d6c0fresolvedReviewed. Forbids caching session validity across requests.
  • Belief belief:2ac590 @ 31d6c0fresolvedRevocation latency is a compliance requirement, not a performance preference.
  • Document docs/security/session-lifecycle.md §4 @ 8be1207resolvedDescribes the one-request revocation guarantee this PR would relax.
  • Belief belief:91de44 @ 5c0a7f2staleCites a rate-limit budget that changed after capture — carried forward as an open challenge, not counted as proof.
Review · proof adequacy3 of 4 criteria met

How much proof this finding actually had

Adequacy is reported before the verdict is acted on. A finding backed by three criteria and one failure is still a finding — it is simply not presented as if it were backed by four.

  • A reviewed decision directly governs the changed symbolmetdecision:7f21c8, human-reviewed, cited at its recording revision.
  • The change is resolved to exact revisionsmetOne symbol, one commit, one ref — no fuzzy diff matching.
  • Every citation still resolves at its recorded revisionnot metThree of four resolve. belief:91de44 is stale and is excluded from the verdict.
  • A second independent source corroborates the findingmetdocs/security/session-lifecycle.md §4 states the same guarantee.
Receipt signedEd25519the failed criterion is shown, not hidden
Review · abstentionInsufficient evidence

Does this change affect the billing webhook retry budget?

No reviewed decision, belief, or document in the graph connects the auth middleware to the retry budget. Review has an opinion available and declines to publish it as a finding.

This is the behaviour that makes the other findings worth reading. A reviewer who has seen Review abstain once can trust that the findings it does publish were not manufactured to fill a comment box.

no finding published · recorded as an abstention

Illustrative example — not live data

What exists today

Contracts shipped. Engine in progress.

ADR-023 and the exact-change contracts are real and merged. The engine that consumes them is three issues in progress. The managed path that answers on your pull requests is designed and not built, and depends on hosted Lens landing first.

  • Exact-change contracts

    Shipped

    The interface that resolves a diff to exact symbols at exact revisions. Specified in ADR-023 and shipped.

  • Local exact-change engine

    Evolving

    Phase A: running the change extraction and evidence query against a local evidence graph. In progress.

  • Deterministic verdicts

    Evolving

    Findings that are a function of the change and the graph, so a re-run cannot quietly change its mind.

  • Proof-adequacy receipts

    Evolving

    A per-finding record of which adequacy criteria were met, which failed, and which citations were excluded.

  • Explicit abstention

    Evolving

    When the graph does not support a finding, Review says so instead of generating one. Abstention is a result, not a failure.

  • Portable review capsules

    Planned

    Phase B: the finding and its receipt sealed into a signed artifact another tool can re-verify.

  • ReviewBench

    Planned

    A deterministic, CI-blocking benchmark for review quality, published the way TrustBench is.

  • Managed review on hosted PRs

    Planned

    Phase C: Review responding on pull requests from the cloud plane. Designed, not built — it depends on hosted Lens.

Status labels follow docs/PRODUCT-DESIGN.md. "Shipped" means substantially implemented; "Evolving" means real foundations with active work remaining; "Planned" means designed and not yet built.

Review changes against what your team already decided.