Broken
Every settled transaction balances to zero
143 of 500 unbalanced. Partial captures leave a dangling debit.
Software correctness platform
Software that runs is not software that works.
Point Vernier at a repository. It works out what your product guarantees, then proves each one with evidence.
200 OK, and the customer was charged twice.
Read-only GitHub access. Your code is never used to train anything.
A green build tells you almost nothing.
- A request can return 200 and still charge the customer twice.
- An endpoint can respond successfully and still hand back another tenant's record.
- A cancellation can complete cleanly while the renewal quietly stays active.
Every one of these is a passing test, a green monitor, and a broken product.
The most expensive thing in software is an assumption nobody wrote down.
Nothing answers the second question.
Is it running?
- Logs.
- Metrics.
- Traces.
- Uptime.
Is it correct?
Nobody was answering this one.
Observability answers "is the system running?" Tests answer "does this function still do what someone wrote down two years ago?" Nothing answers "is this guarantee still holding?"
Because nobody wrote the guarantees down.
Why the usual answers don't close the gap.
These are all answers to "what happened?". Vernier answers "what is supposed to be true, and is it?"
A test encodes what one engineer believed, on one afternoon, about one path. It passes forever after, including long after the belief stopped being true. Coverage measures how much code ran, never how much of your product's meaning is protected.
A model reading a diff sees a few hundred changed lines and none of the product those lines serve. It can tell you this loop is O(n²). It cannot tell you that this change breaks the invariant that every settled transaction balances to zero, because it was never told that invariant existed, and it will not go and find out.
Logs, metrics and traces describe a system's health, not its correctness. They are exceptional at telling you something is on fire. They are silent when everything is calm and wrong.
How it works
01
Connect
Install the GitHub App on a repository. Read-only. Nothing runs in your infrastructure.
02
Understand
Vernier reads the codebase and infers its capabilities, the product areas, and the behaviors inside them: the specific claims your software makes about itself. "A refund never exceeds the captured amount." "Replaying a request with the same idempotency key returns the first response." These are extracted from the implementation, not from documentation nobody has updated.
03
Verify
For each behavior, Vernier designs an experiment, runs it in an isolated sandbox, and records what it observed. A behavior becomes Proven only when evidence supports it, and Broken only when a failure actually reproduced.
04
Watch
Every push and pull request is checked against the standing model. When a change puts a guarantee at risk, Vernier verifies that guarantee specifically and tells you what moved, before the merge rather than after the incident.
The output is not a score. It is a list of things your product promises, each one marked with whether it currently holds and what evidence says so.
Nothing crashed. Nothing alerted. The tests still passed.
| Beat | State | What Vernier observed |
|---|---|---|
| 1 | Not verifiedNot verified | Vernier found this claim in your code. |
| 2 | InvestigatingInvestigating | Designing an experiment. Running it in a sandbox. |
| 3 | ProvenProven | 500 synthetic transactions. All balanced. reconcile.ts |
| 4 | ProvenProven | Still holding. Commit after commit, for four months. |
| 5 | InvestigatingInvestigating | A change touched settlement. Re-checking. |
| 6 | BrokenBroken | 143 of 500 unbalanced. Partial captures leave a dangling debit. |
This is a regression, not a discovery. Vernier knew this was true yesterday.
The vocabulary
| Term | Meaning |
|---|---|
| Capability | A product area. Contains behaviors. |
| Behavior | One claim your product makes about itself. The atom of the model. |
| Investigation | An open question about whether a behavior holds. |
| Run | An execution that tries to answer an investigation. |
| Evidence | What a run actually observed. File paths, counts, outputs. |
| Issue | A reproduced failure. Not a warning, not a suspicion, not a lint hit. |
Most tools inflate "issue" until it means "something we noticed". Here it means a failure Vernier caused to happen again, on purpose, and can show you.
Your guarantees outlive your commits.
A behavior is not a finding that appears in one report and vanishes from the next. Each one has a durable entry in the ledger: when it was first discovered, every commit it has been seen at, the last commit where it was verified, and every state it has ever moved through.
So when a guarantee that was Proven four months ago quietly stops holding, that is not a new issue with no history. It is a regression, with a before, an after, and the change in between.
You can also correct it. Confirm a claim Vernier inferred, reject one that isn't real, or reword it in your own language, and your wording is kept rather than overwritten on the next analysis.
See what your product promises, all at once.
Capabilities, the behaviors inside them, the investigations attached to each, and the evidence underneath, as one graph you can read.
Verification state is carried by shape and weight, not colour alone, so a broken guarantee is visible at a glance and still visible to anyone who doesn't see colour the way you do.
You don't navigate Vernier. You talk to your repository.
There is no dashboard to learn and no navigation tree to click through. One surface: a conversation on the left, and a canvas on the right that the agent drives.
Ask "which behaviors are broken right now?" and the issues open beside the answer while it is still being written. Ask "why?" and the evidence, the failing run and the affected files are already on screen.
The canvas moves before the answer finishes.
You are reading the view and the explanation at the same time, not waiting for prose to end so you can go looking.
Every view is still a URL.
Anything the agent opens can be linked, shared and bookmarked.
Conversations are durable.
Close the tab, come back tomorrow, and the thread and what it was looking at are both where you left them.
It can do the work. It cannot do it behind your back.
Vernier's agent isn't limited to answering. It can review the behavior ledger, submit an evaluation, pause autonomous verification, or re-index the repository.
Every one of those becomes a card in the conversation with Approve and Reject on it. Nothing reaches your project until you click. Ask it to confirm six behaviors and you get one card for six, not six cards, and the agent tells you it proposed the change, never that it made one.
Work that starts something happens immediately: running a verification, re-checking an issue, syncing changes from GitHub. You can watch those and stop them. Work that edits your record waits for you. That distinction is the whole design.
Delegate a morning's work. Close the laptop.
Ask for something wide, like "verify every broken behavior and investigate the ledger regression", and the lead agent dispatches named sub-agents, each with one objective, each running server-side.
They appear as live cards: what the agent is called, what it was asked to do, the line it is on right now, and what it concluded.
settlement-audit
Re-verify every broken behavior in settlement.
Running experiment 3 of 9
ledger-regression
Find the commit where the balance invariant stopped holding.
Reading evidence at c72ae18
refund-invariants
Check refund ceilings against captured amounts.
Concluded. 2 proven, 1 inconclusive.
These agents run on Vernier's servers. Closing the tab does not stop them.
A hard concurrency cap, visible progress on every agent, and a stop button on each one. No hidden fan-out, no silent token burn.
"This change breaks a guarantee" beats "this change looks risky".
On every pull request, Vernier maps the diff onto the behaviors it touches, verifies the ones actually at risk, and posts what moved.
- Which guarantees this change puts in play.
- Which of those still hold, with the run that proved it.
- Which broke, with the reproduction.
- Which it could not determine, and why.
No approval theatre, no paragraph of hedged suggestions. A verdict about your product, with the evidence attached.
A report you can hand to someone who has never opened the repo.
- Behavioral health
- Are the guarantees holding? Green, amber, or at risk.
- Verification coverage
- How much of your product's meaning has actually been checked?
They are never collapsed into a single score, because a product with 95% coverage and one broken invariant in settlement is not "95% fine".
Built only from what Vernier has actually observed. No estimated risk, no invented causes, no vanity metric.
Five states, and one of them is an admission.
- Proven
- Evidence supports the claim, at a specific commit.
- Broken
- A failure reproduced. There is an issue behind it.
- Investigating
- A run is in flight right now.
- Not verified
- Vernier knows this claim exists and has not yet checked it.
- Inconclusive
- Vernier tried and could not establish either answer.
Who this is for
Teams where being wrong is expensive.
Payments, ledgers, billing, identity, healthcare, infrastructure. Anywhere a silent incorrect success is worse than a loud failure.
Engineers inheriting a codebase.
The fastest honest answer to "what is this system actually supposed to do?"
Teams shipping fast on code they didn't all write.
Including code written by agents, which is most of the reason this problem is getting worse.
Anyone who has had the same incident twice.
Security and deployment
- Read-only GitHub App.
- Vernier reads code and metadata. It does not write to your repository.
- Nothing runs in your infrastructure.
- Verification executes in isolated sandboxes on Vernier's side.
- Your code is not training data.
- Not for us, not for a model provider.
- You can turn the agent off.
- A single switch disables all autonomous behavior and blocks every staged action, including ones already waiting for approval.
The questions you were about to ask
Isn't this just AI code review?
No. A code reviewer looks at a diff. Vernier maintains a standing model of what your product guarantees and checks changes against it. The unit of work is a behavior, not a pull request, and the output is a verdict backed by a run, not a suggestion.
How do I know it isn't hallucinating behaviors?
You review them. Inferred claims arrive as candidates and stay candidates until you confirm, reject or reword them. And a behavior is only ever Proven or Broken off the back of a run whose evidence you can open and read.
Our test suite is good.
Then Vernier will find that most of your behaviors are Proven and tell you which ones your suite never touches. The interesting output isn't the failures. It's discovering which guarantees nothing was checking.
We can't run untrusted code against our systems.
You don't. Verification runs in an isolated sandbox against your code, never against your production environment.
What happens when it can't figure something out?
It says Inconclusive and shows you why it got stuck. It does not guess and it does not quietly drop the behavior.
How long until it's useful?
First analysis on a repository takes [N minutes]. You have the behavior model and the first verification results in the same session.
Find out what your product actually guarantees.
Connect a repository. Read the behaviors Vernier infers. Decide for yourself whether they're the right ones, then let it start proving them.
Free while we're in [early access]. No credit card, no call required.