Software correctness platform
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.
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.
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.
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.
01
Install the GitHub App on a repository. Read-only. Nothing runs in your infrastructure.
02
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
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
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.
Every settled transaction balances to zero
143 of 500 unbalanced. Partial captures leave a dangling debit.
| 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.
| 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.
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.
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.
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.
You are reading the view and the explanation at the same time, not waiting for prose to end so you can go looking.
Anything the agent opens can be linked, shared and bookmarked.
Close the tab, come back tomorrow, and the thread and what it was looking at are both where you left them.
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.
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.
Re-verify every broken behavior in settlement.
Running experiment 3 of 9
Find the commit where the balance invariant stopped holding.
Reading evidence at c72ae18
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.
On every pull request, Vernier maps the diff onto the behaviors it touches, verifies the ones actually at risk, and posts what moved.
No approval theatre, no paragraph of hedged suggestions. A verdict about your product, with the evidence attached.
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.
Payments, ledgers, billing, identity, healthcare, infrastructure. Anywhere a silent incorrect success is worse than a loud failure.
The fastest honest answer to "what is this system actually supposed to do?"
Including code written by agents, which is most of the reason this problem is getting worse.
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.
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.
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.
You don't. Verification runs in an isolated sandbox against your code, never against your production environment.
It says Inconclusive and shows you why it got stuck. It does not guess and it does not quietly drop the behavior.
First analysis on a repository takes [N minutes]. You have the behavior model and the first verification results in the same session.
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.