Noise control
A reviewer that comments on everything gets muted. inline’s trust comes from the opposite instinct: comment only when confident it’s right, and treat zero comments as a successful review. Everything the model submits passes through a validation gate before a single comment is posted.
Suppressed findings are never dropped. Each is stored with a reason and remains visible in the portal — so you can audit what inline chose not to say, and tune the thresholds if it’s being too shy or too loud.
# The validation gate
The gate runs after the deep review and before posting. A finding is suppressed for any of these reasons:
| Reason | Trigger |
|---|---|
| Low confidence | Confidence below the floor (default 0.55). |
| Below threshold | Severity below the repo’s threshold (default medium). |
| Duplicate | Already posted earlier in this PR, or seen twice this review. |
| Invalid line | Points at a line not present in the PR diff (after a recovery attempt). |
| Comment cap | Beyond the postable-findings cap (default 12). |
# Confidence floor
Every finding carries a model-assigned confidence from 0 to 1. In production tuning, confirmed-real findings clustered around 0.55–0.60 while dismissals clustered at 0.80+, so the floor sits at 0.55. Below it, a finding is stored but not posted.
# Severity threshold
Each repo has a severity threshold (low / medium / high, default medium). Findings below it are suppressed. Set it per-repo or per-workspace in review config — a mature codebase might raise it to high; a security-critical one might drop it to low.
# Dedup fingerprints
Each finding gets a stable fingerprint built from the repo, PR, file, a normalized title, and a coarse line bucket:
- The normalized title is lowercased and stripped to its first several words — so trivial rewordings collapse to the same identity.
- The line bucket is coarse — so small line shifts from later edits don’t resurrect a finding as “new.”
The same normalization drives the feedback loop’s dismissal grouping, so a proposed suppression rule covers exactly the findings that share an identity.
# Line anchoring
GitHub inline comments can only attach to lines that appear in the PR diff. When a finding’s line doesn’t:
- A range with one valid endpoint collapses to that endpoint.
- Otherwise inline snaps to the nearest commentable line within a short window, and adds a “📍 anchored to the nearest changed line” note.
- If nothing anchors, the finding is suppressed and surfaced in the walkthrough’s “Additional findings” section instead.
# Comment cap
At most 12 findings are posted. When the model produces more, they’re sorted by severity then confidence, and the lowest are dropped to the cap (still stored, still visible). This bounds the blast radius of a noisy review.
# Prompt-level discipline
The gate is the backstop; the review itself does the first-line filtering. The reviewer role is explicit:
- A review with no findings is a SUCCESS. Don’t invent problems to look useful.
- Never comment on style, formatting, naming, documentation, or test coverage.
- Refute your own finding before flagging it — if you can talk yourself out of it, don’t post it.
- Calibrate confidence honestly against a rubric.
# Tuning
The confidence floor and comment cap ship with sensible defaults. Severity threshold and custom instructions are set per-repo or per-workspace in the portal. If inline is too quiet, lower the threshold or the confidence floor; if too loud, raise them or add a learning that teaches it to stop flagging a specific pattern.