00TraceAxiom Verify / in development
Run the pull request before you merge it.
Verify is a GitHub Action that tests an AI-written pull request against the branch it targets, checks whether the tests would catch a broken version of the change, checks what the pull request claims, and posts one verdict with its reasons.
01Problem
Coding agents open pull requests faster than people can review them.
An agent can write a pull request in minutes. Reading it properly still takes a person much longer, and the description the agent writes is a claim, not evidence. A change described as a dependency bump can also edit source files. A test suite can pass because the change weakened the tests it was meant to satisfy. A new import can name a package that does not exist.
Review bots read the diff and give an opinion. Verify takes a different route: it runs the change. It compares the pull request against the branch it targets, checks the specific claims that can be checked mechanically, and reports what it found and what it could not establish.
- Runs the change instead of reading it
- Checks claims, not style
- States what it could not check
02How it runs
A GitHub Action in your own CI, posting one verdict per pull request.
On a pull request, Verify checks out the base and the head, detects the stack, installs the project and runs its existing tests on both. Then it runs the claim checks and mutation testing, and posts one comment with a verdict and the reasons for it. When the run repeats, it updates the same comment instead of adding another.
Because it is an Action, it runs on your CI runners rather than on a TraceAxiom server. Node and TypeScript repositories come first, with npm, pnpm or Yarn 2+. A repository Verify cannot build or test gets the verdict “couldn't run” with the reason, instead of a guess.
- Base and head both tested
- Node and TypeScript first
- One comment per pull request, updated in place
03Controls
Test results that a change cannot quietly fake.
A test run is only evidence if its results are real. Verify reads each test's result through its own reporter, and before the run it plants two control tests in every test file: one that must pass and one that must fail. If a change switches the tests off, forges their output or imitates a passing run, the controls show it.
On GitHub's runners the pull request's code runs as a separate user. Before each run, Verify checks on the runner that this user cannot read the repository's git credentials, the event that started the run, or Verify's own files.
- Its own test reporter
- One control that must pass, one that must fail
- Pull request code runs as a separate user
04Mutation testing
Would the tests notice if the changed lines were wrong?
Passing tests prove little if they never exercise the change. After the change's own tests pass, Verify makes small deliberate breaks in the lines the pull request changed, using StrykerJS, and reruns the project's tests to see whether they notice.
A code change can be accepted only when its tests catch at least 60% of those breaks and every other check holds. The comment names the breaks no test noticed, so a reviewer knows exactly where the tests are thin.
- Only the changed lines
- Accept needs at least 60% caught
- Uncaught breaks are named
05Claim checks
Three checks on what the pull request says it is.
Dependency-bump check: whether a change only bumps dependency versions, or also changes code. Test-surface check: whether the change touches the files the tests themselves depend on, so a passing run cannot be taken at face value. Dependency-existence check: whether every newly added npm dependency exists in the registry, which catches package names an AI model made up.
These checks run on real pull requests in TraceAxiom's own repository. The site quotes no accuracy figures for them yet.
- Dependency bump only, or not
- Touches what the tests depend on
- Every new npm dependency exists
06Verdicts
Four verdicts, each with its reasons.
Accept means the checks Verify ran found nothing that should block the change. Needs review means something deserves a person's attention, and the comment names it. Reject means a check found a concrete problem, such as a test that passed before the change and fails after it; the comment names the broken tests. Couldn't run means Verify could not complete the checks, and it says which step failed.
A verdict covers only the checks that ran. The comment lists those checks, so a reader can see what an accept actually rests on.
- Accept
- Needs review
- Reject
- Couldn't run
07Status
No one outside TraceAxiom can install Verify yet.
Verify posts its verdict as a comment on real pull requests in TraceAxiom's own repository, since 3 October 2026. Built: tests on base and head, control tests, the separate user, the three claim checks, mutation testing of the changed lines, the verdict comment, and support for npm, pnpm and Yarn 2+. 444 automated tests pass on Verify's main version.
Not built yet: signed receipts end to end, independent tests written by AI, and the install flow. This page will change as each one ships.
- Verdict comments on our own pull requests
- Mutation testing built
- Signed receipts not live yet
- Not installable yet
Design partners
Use Verify on your repositories first.
Verify is not installable yet. Join the waitlist to hear the day it is. Teams whose pull requests come from coding agents can also become design partners and use it first.
Join the waitlist