AI code review that verifies before it comments.
Veridical reviews GitHub pull requests with the context, tools, and evidence needed to separate a real defect from a convincing guess. Maintainers get fewer comments—and stronger reasons to act on them.
What reaches the pull request
- Findings
- Affected code, consequence, and concrete evidence
- Coverage
- What was read, run, skipped, or degraded
- Receipt
- The exact commit and terminal review state
A pull-request reviewer should earn every interruption.
Faster generation increased the amount of code teams must review. The answer is not a larger stream of comments. It is a review path that knows what changed, investigates what the change depends on, and withholds claims it cannot support.
Bind the review to the change
The base, head, files, checks, and findings belong to one immutable pull-request head. A newer commit never makes an older receipt current.
Read the context the diff leaves out
Callers, interfaces, configuration, tests, and declared dependency boundaries stay available when the changed lines alone cannot answer the question.
Turn claims into evidence
When a finding can be checked, the review uses the repository's tools and runtime to distinguish a reproducible defect from plausible commentary.
Publish only a terminal decision
Grounding, relevance, lineage, and final verification determine what reaches maintainers. Internal model votes are never presented as evidence.
Model-only review describes. Verifiable review decides.
Models remain useful discovery instruments. The quality boundary is what happens after they speak: whether the claim is grounded, tested where possible, and allowed to fail before it reaches a maintainer.
| Boundary | Model-only review | Veridical review |
|---|---|---|
| Input | A diff or prompt window | Exact PR head plus relevant repository and dependency context |
| Candidate | A fluent explanation | A claim tied to code, consequence, and affected region |
| Validation | Model confidence | Source grounding, deterministic evidence, or repository-native checks |
| Output | A stream of suggestions | Verified inline findings and one exact-head decision record |
| Repair | Patch the selected comment | One separate repair PR for the published actionable set, then re-review |
Evidence you can inspect.
The useful question is not whether an AI reviewer sounds intelligent. It is whether the finding survives contact with the source, the runtime, and the exact code that would ship.
AI code review, answered plainly.
- What is AI code review?
- AI code review uses models and software analysis to inspect a proposed change, identify defects, and return feedback before merge. Veridical adds a verification layer: a candidate must survive grounding and terminal checks before it becomes a published finding.
- Does Veridical review more than the Git diff?
- Yes. A pull request is the starting point, not the complete evidence boundary. The review can inspect unchanged callers, interfaces, repository context, declared dependencies, and cross-repository changes needed to evaluate the exact head.
- Where does the review appear?
- Verified findings appear beside the affected lines in GitHub, with one exact-head summary and a complete evidence record in the Veridical app.
- Can Veridical fix the findings?
- A reviewed pull request can produce one separate repair pull request covering its published actionable findings. The repair is checked and re-reviewed, and is never auto-merged.
- Is AI code review free for open source?
- Eligible public open-source repositories can receive recurring review capacity without a card. Fair-use, concurrency, repository, diff-size, and per-review safety limits still apply.
Put evidence on your next pull request.
Connect a public open-source repository through the GitHub App. The first 50 activated repositories receive five Ultra reviews every month without a card.