Other AI reviewers guess. We verify.

Verified pull-request reviews, delivered inside GitHub. Connect selected repositories and get evidence-backed findings on every exact head.

We lead the field on real defects.

Leaderboard - F1

Board: live published rows · Veridical: projected onto the same scale

projected #1

ReviewerF1PRF0.5
Veridical - projected onto the board's scale
Veridicalprojected
6475.855.370.6
Live board - codereview.withmartian.com
Gemini Code Assist
59.272.949.866.7
Greptile
57.174.546.366.4
Claude
55.864.149.360.5
CodeRabbit
55.064.947.760.5
Cubic Dev AI
54.071.843.363.4
Cursor
52.773.741.063.6
Qodo
48.862.340.256.1
GitHub Copilot
48.462.039.655.7

The leaderboard is the public board's own scale (codereview.withmartian.com, current month). The Veridical row is a projection onto that scale; the others are live board listings. Read a projected row and a live row as two different measurements. F0.5 is computed from each tool's precision and recall.

On identical pull requests, on the question that decides real value - is the finding a real defect? - we out-find every tool we tested: F1 67-72 versus 50-58, beating the board’s current #1 by +9.0. On the board’s own acted-on scale the Veridical row is a projection (F1 64) - shown as a projection, not a live listing. Our instrument reproduces the live board within ±1 F1 for every tool.

Review pull requests in GitHub.

Choose repositories once. Verified findings and the final summary stay beside the code.

Read permissions and supported events
  1. 01

    Connect GitHub

    Install the app only on the repositories you choose.

  2. 02

    Open a pull request

    Veridical reviews the exact commit and follows each new head.

  3. 03

    Review verified findings

    Inline comments and one summary keep the evidence beside the code.

See exactly what we caught

Not a wall of suggestions. The handful of findings that would have 500'd a request or leaked a tenant - each posted on the line, with the failing input that proves it.

A different catch every few seconds

Each one a confirmed bug - the failing input that proves it and a safe-to-merge read-out, posted inline. Data loss, auth leaks, crashes, races.

github.com/discourse/discourse
Auth disclosureblocking

app/models/topic_link_click.rb:95

Veridicalbot

A link-click fallback returns a stored link’s URL without re-running the visibility check - a user can confirm and obtain redirect URLs for links inside private topics they cannot access.

verifiedcreate_from(mismatched post/topic) → returns link.url, no can_see? check
safe-to-merge0.11

gate requires ≥ 0.95 to merge

Real catches · hover to pause

The verdict on the PR

Every finding ranked by what it costs you, behind one gate you can merge against.

Veridical · 2 findings · 1 blocking
Blocked - 1 unresolved regression
14 files reviewed+218 −96ranked worst-first

Link-click fallback skips the visibility check

app/models/topic_link_click.rb:95Auth disclosure

create_from(mismatched post/topic) → returns link.url, no can_see?

0.12

Visibility guard silently drops valid clicks

app/models/topic_link_click.rb:107Silent data drop

link.post == nil on a public topic → create_from returns nil

0.40
Gate: safe-to-merge ≥ 0.95currently 0.18

PR summary · gated on safe-to-merge

One number your merge policy can use.

Every review carries an evidence-backed advisory score. Your repository owns the threshold and the merge decision, while Veridical supplies the findings, execution evidence, and exact-head check.

Merge box · GitHub
github.com/getsentry/sentry/pull/118240
j-rivera wants to merge 2 commits intomain

Some checks were not successful

1 failingand3 successful checks

  • CI / build(20.x)Successful
  • CI / unit342 passedSuccessful
  • CI / lintno problemsSuccessful
  • Veridical / safe-to-merge1 counterexampleFailing
Veridicalsafe-to-merge
0.18

HOLD - safe-to-merge 0.18counterexample attached

ConfigStore.get('signupLocalities') === undefined → .includes() throws

Merging is blocked - a required check is failing.

.veridical.ymlmain
.veridical.ymlYAMLvalid
1version: 123# Gate the merge button on a calibrated score4auto_merge:5 gate: safe-to-merge >= 0.956 require_clean_ci: true78# Hold & comment on anything below the bar9on_hold:10 attach_counterexample: true11 block_merge: true12 comment: "veridical/findings"
required check activegate ≥ 0.95YAML · LF · UTF-8

Cross-stack causality

Your code tools see the diff. Your SRE tools see the alert. Neither connects the two. We do. One view traces a production incident back through the deploy, the migration, and the constraint - to the exact guest-path line that violated it.

veridical.app/incidents

Integrations 500s

resolved
Ask across your stack…
Integrations 500s14:32 → 14:5119m

A System Map that writes itself

Code, deploys, and data on one graph. Every module gets a wiki page that’s right the moment main moves - purpose, signatures, callers, the changes worth watching, and who owns it.

Ask anything about this codebase…
use-cache /

tiered-cache-handler.ts

auto-generated

updated 2h agoalways current with main327 lines

Purpose

Coordinates the in-memory and persistent cache tiers: serves warm reads and schedules background revalidation/sync after a read, so the next request gets fresh data without blocking.

Key functions

4 exported
  • 37scheduleBackgroundSync(store: WorkStore)
  • 58get(key: string): CacheEntry
  • 92set(key: string, entry: CacheEntry)
  • 120executeRevalidates(store: WorkStore)

Callers

4
use-cache/use-cache-wrapper.tscacheLife()server/app-render.tsxrenderToStream()use-cache/cache-handler.tsget()lib/incremental-cache.tsrevalidate()

Recent risky changes

  • high riskConcurrent warm reads serialize teardown - the Nth request blocks ~N×200mstiered-cache-handler.tsL372h ago
  • watchAn undefined work store silently leaves background syncs untrackedtiered-cache-handler.tsL41yesterday
  • routineAdded a read-through tier to the persistent cachetiered-cache-handler.tsL883 days ago

Owners

ARJKMP
A. Rios + 2 · CODEOWNERS

Straightforward pricing.

Choose individual review capacity or pool credits, controls, and repository tooling across your team.

One workspace, one owner. Upgrade when you need repository-wide tooling.

Launch tier

Availability updating

Evidence-backed pull-request reviews for public and private repositories.

$0

per workspace

Reviews only · no card required

Start free

5

Ultra reviews monthly

Shared across all repositories in one workspace. Available to the first 50 workspaces that connect a repository; registration alone does not reserve a place.

  • Public and private GitHub repositories
  • Ultra review depth, as in our public demo
  • Exact-head GitHub review
  • Verified inline findings
  • Complete review summary and verdict
  • Review history and evidence receipts
  • Monthly allowance refreshes in UTC
  • Review-only access; no repository scans or repairs

Standard

Production pull-request reviews without the wider repository operations suite.

$39

/month

Choose Standard

12

credits each month

40,000 reviewed lines included monthly.

  • 12 review credits each month
  • 40,000 reviewed lines each month
  • Exact-head GitHub review
  • Verified inline findings
  • Complete review summary and verdict
  • Review history and evidence receipts

Pro

Recommended

Higher review capacity plus the repository, security, and support tools around each change.

$69

/month

Choose Pro

20

credits each month

100,000 reviewed lines included monthly.

  • 20 review credits each month
  • 100,000 reviewed lines each month
  • Everything in Standard
  • Manual and scheduled codebase scans
  • Repository knowledge and code graph
  • CLI early access (work in progress)
  • 24/7 priority support

How plan allowances work

What does the free Launch tier include?View
5 Ultra reviews per workspace each UTC calendar month, shared across all connected public and private repositories. Launch is review-only: repository scans, repair workflows, and the wider Pro suite are not included. The allowance does not grow when you connect more repositories.
Can one plan run different review depths?View
Yes. The subscription controls capacity and product access; the engine still routes each paid pull request to the review depth its evidence requires. Launch, Standard, and Team Standard are review-only. Pro and Team Pro unlock the wider repository suite.
How are larger pull requests charged?View
Normal · 1×
Up to 2,000 lines, 50 files, and 256 KiB
Large · 2×
Up to 8,000 lines, 200 files, and 1 MiB
Very large · 3×
Up to 20,000 lines, 500 files, and 2.5 MiB
Beyond
A clear, capped quote before the review starts
Do credits roll over?View
Credits refresh each month and do not roll over. There is no automatic overage; change seats or contact us before you need more pooled capacity.

A separate grant for open-source projects.

Eligible public projects receive 5 Ultra reviews per project each month after approval. Need more? Apply for a higher monthly grant. OSS capacity is approved separately; connecting an OSS repository does not automatically add reviews to your Launch allowance.

Apply with a public repository