00The AI factory, today
Software is now made in factories. Verify inspects every change.
Coding agents now write pull requests around the clock, faster than anyone can read them. Verify is the inspection line at the end of the factory: a GitHub Action that runs every change before it merges, checks what it claims, and posts one verdict with its reasons.
- Runs your tests before and after the change
- Breaks the changed lines to see if the tests notice
- Checks what the pull request claims
- Posts one verdict, with its reasons
01The output
The factory never stops. Review does.
A coding agent writes a pull request in minutes, day and night. A person still needs far longer to read one properly. So the pile grows, every review gets a little thinner, and things start falling through.
The description an agent writes is a claim, not evidence. It can call a change a dependency bump while the code also edits source files.
02Inspection by looking
Most code is still inspected by looking at it.
Review bots read the diff and give an opinion. The defects that matter often look fine: tests that pass because the change weakened them, or an import that names a package nobody ever published.
Looking lets them through. Running the code finds them.
03The turn
Put an inspection line at the end of the factory.
Every pull request passes through Verify before it can merge. It checks out the branch the change targets and the change itself, runs them, and reports only what actually ran.
04Two lanes
The same tests, before the change and after it.
Base and head
BuiltThe project's own install and tests run on the target branch and on the pull request. A test that passed before and fails after is named in the comment.
Control tests
BuiltVerify plants two tests in every test file: one must pass, one must fail. If a change switches the tests off or fakes their results, the controls show it.
A separate user
BuiltOn GitHub's runners the pull request's code runs as a user that cannot read the repository's credentials or Verify's own files. Verify checks that before every run.
05Claim checks
The description is a claim. Verify checks it.
- Dependency bump only?A change that calls itself a version bump should touch nothing else.
- Touches what the tests depend on?If a change edits the files its own tests rely on, a passing run cannot be taken at face value.
- Every new package real?Each newly added npm dependency is looked up in the registry, which catches names an AI model made up.
06Stress test
Would your tests notice if these lines were wrong?
After the change's own tests pass, Verify breaks the lines the pull request changed, one small break at a time, and runs the tests again.
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 each break that no test noticed, so you know exactly where the tests are thin.
07No guessing
When it can't check something, it says so.
“Couldn't run” is a verdict, not a shrug. When Verify cannot build or test a repository, it stops and names the step that failed.
Every comment lists the checks that did not run, so a reviewer can see what an accept actually rests on. A check that did not run is never reported as passed.
08The verdict
One comment. Four possible verdicts.
- AcceptThe checks found nothing that should block it.
- Needs reviewSomething deserves a person's attention, and it is named.
- RejectA check found a concrete problem, such as a broken test.
- Couldn't runThe checks could not finish, and the failing step is named.
verdict needs review · 1 reason pull request #42 · base 3e41c07 · head 7f2a91d tests base pass · head pass controls held in every test file mutation 7 of 9 breaks caught on changed lines claim “dependency bump” · diff also edits src/merge.ts packages lodash 4.17.21 · found in npm registry not run independent tests (not built yet)
Illustrative example, not a real run.
09The receipt
Every verdict leaves with a receipt.
Each verdict will come with a receipt: the exact commits, the checks that ran, the ones that did not, and the verdict itself. Anyone holding it will be able to confirm nothing was changed after the fact.
Signing is written and tested in code. Signed receipts are not live end to end yet. Not built yet
10Where it stands
What works today, and what doesn't yet.
Since 3 October 2026, Verify posts its verdict as a comment on real pull requests in our own repository. 444 automated tests pass on its main version.
- Tests on base and headThe project's own install and tests run on the branch the pull request targets and on the pull request.Built
- Control testsTwo planted tests in every test file, one that must pass and one that must fail, for Node's test runner, Jest and Vitest.Built
- Separate userOn GitHub's runners the pull request's code runs as a user that cannot read the repository's credentials or Verify's own files.Built
- Claim checksDependency bump only, touches what the tests depend on, every new npm dependency exists.Built
- Mutation testingThe changed lines are broken one small change at a time to see whether the tests notice.Built
- Verdict commentOne comment per pull request, updated in place when the run repeats.Built
- Package managersnpm, pnpm and Yarn 2+ projects install and run on GitHub's runners.Built
- Signed receiptsWritten and tested in code, not yet signed end to end.Not built yet
- Independent testsTests written by AI, separately from the change, are not built yet.Not built yet
- Install flowNo one outside TraceAxiom can install Verify yet.Not built yet
We publish no usage, accuracy or speed figures until real runs on other people's code exist.
11The future
Picture every line ending at a gate.
Agents build around the clock, everywhere. Every change they make arrives with a receipt anyone can check. Low-risk work merges on proof, people spend their attention where it matters, and nobody has to take a model's word for what it did. That is the world TraceAxiom is building toward.
- NowVerify, the inspection line for pull requests. Being built.
- NextSigned receipts anyone can check offline, and independent tests written by a different model.
- ThenChanges that merge on proof. An open receipt standard. A referee agents call themselves.
- The WorkspaceA live 3D view of your own factory, like this one, built only from real events.
- Beyond codeThe same referee for any AI work: claims checked, records kept, verified work insured.
12The founder
Built by Arhan Canli.
Founder and lead engineer. TraceAxiom started from one question: when an agent writes the code, who checks it? The answer had to be someone who never writes the code, and never grades their own work.
The site keeps the product's rule. Built means built. Examples are labelled. No figure appears before a real run.
13The waitlist
Join the waitlist.
Verify is not installable yet. Join the waitlist and you will hear the day it is. Teams whose pull requests come from coding agents can also become design partners: they use it first and help decide what it checks.
- Open sourcePlanned to be free for open-source projects.
- Design partnersHalf of list price, agreed in writing before anything is charged.
- Your own CIVerify runs on your own CI runners, not on a TraceAxiom server, so it uses your CI minutes.
- List pricePublished before launch. Nobody pays before they have seen it.
Questions
Plain answers.
What does TraceAxiom Verify do?
Verify is a GitHub Action, in development, that runs a pull request's existing tests on the base branch and on the pull request, mutation-tests the changed lines, checks what the pull request claims, and posts one comment with a verdict and its reasons.
How is it different from an AI code review bot?
A review bot reads the diff and gives an opinion. Verify runs the change: it compares test results on base and head, checks whether the tests would notice broken versions of the changed lines, and checks claims such as “dependency bump only” or “every new npm package exists” mechanically.
What verdicts can it give?
Accept, needs review, reject, or couldn't run. Each comes with its reasons. Couldn't run means Verify could not complete the checks, and the comment says which step failed.
Which languages does it support?
Node and TypeScript repositories first, using npm, pnpm or Yarn 2+. Other stacks come later.
Can I install it today?
Not yet. No one outside TraceAxiom can install Verify today. Join the waitlist to hear the day it is installable; teams whose pull requests come from coding agents can apply to be design partners and use it first.
How much will it cost?
Verify is planned to be free for open-source projects. Design partners pay half of list price, agreed in writing before anything is charged. The list price will be published before launch, so nobody pays before they have seen it. Verify runs on your own CI runners, so it uses your CI minutes, not a TraceAxiom server.
What happens after I join the waitlist?
You get one confirmation email. Arhan reads every request and replies personally, usually within two working days. You will hear again when Verify can run on your repositories, and not otherwise.