A model writes the function.
A model writes the test that agrees with it.
Generated tests can mirror generated code instead of challenging what the code was supposed to do. We audit the behavior behind AI-native systems: agent loops, tool calls, generated code, and the tests that were generated next to it, against requirements your architects read and approve. Expert-signed, machine-verified: every finding is validated by a named reviewer before it reaches you.
Fit filter · all three, or it's a no
Series B or later, or revenue that behaves like it. Earlier than that, the money belongs in engineers.
One named person who can approve what the audited path is supposed to do. Not a team alias.
A release that bounced, a Sev-1 nobody can explain, an enterprise security review, or a customer commitment you have to stand behind.
Generated tests can agree with generated code.
The test describes what the function does, so it passes, and it keeps passing while the function drifts, because it was never a statement about what the function was supposed to do. Coverage climbs. The number of independent claims about intended behavior stays where it was.
Teams wrote implementation-shaped tests long before any of this. Volume per review hour is what changed, and volume turns a known weakness into the default.
So week one goes somewhere else. We write down what the path is supposed to do, as requirements your architects read and approve, about two hours of their time per component. After that there's something for the code and the tests to be wrong against.
Then we check
What we take on.
What the loop does when a tool times out, returns malformed output, or answers confidently with something wrong.
The diff nobody read closely, the test that agrees with it, and the requirement nobody wrote down.
Behavior that depends on ordering, cache state, or model output, which your suite sees as flakiness and mutes.
The behavior your docs, security questionnaires, and release notes commit to, checked against what the code does.
Both of these are on our own public library.
jsonparser is ours, so every claim below is verifiable against a public repository rather than described to you second-hand.
keys[depth:][0][0].
The same unsafe assumption survived behind different syntax, on a tree the search had already reported clean. Matching a pattern finds instances. Closing a class needs someone who understands the class.
Set([1,2], "9", "[5]") returned [9]. No panic, valid JSON,
elements gone. Coverage confirmed the branch was reachable and had nothing to say about
which output was correct. We published that as a
postmortem
rather than hardening the tool and saying nothing.
On severity. Severity is our own assessment, weighted by reachability and impact, and it is offered as a starting point for your triage. It is not a CVSS score and not a vendor determination. Every finding ships with a reproducer that runs red on your current main, and a named reviewer validates it before you see it.
The library carries 123 formal requirements and 100% MC/DC, and OSS-Fuzz missed the escaped class because it held key paths fixed. The full entry. The instruments.
Fixed fee, one component, about four weeks.
A Continuous Correctness Audit on one component. Scope is agreed and written down before work starts, so the fee is fixed and the boundary is explicit. One component for the baseline, not a platform-wide sweep.
Pick the path you can least afford to be wrong. We agree the component, the access model, the disclosure boundary, and what's out of scope, in writing.
Week one. We formalize what the component is supposed to do, and your architects review and approve it.
Weeks two and three. Gap analysis against the approved requirements, boundary and fault-tolerance scenarios, invariant checks, and the conditions no coverage number sees.
Each finding carries a code location, a runnable reproducer, a suggested fix, and our severity assessment. Delivered as a live walkthrough, split for executives and for engineers, with the triage boundary published alongside it.
Once you've remediated, we re-verify every finding and re-issue the report with per-finding status, at no additional fee.
After the baseline. Continuous coverage is a monthly retainer at a cadence you set: per release, weekly, or faster. Fix work is scoped separately and never bundled into an audit, and your own engineers can take any finding at identical status.
We take a limited number of engagements each quarter. If a delivered finding fails its own reproducer on the scoped tree, we pull it.
Where this works, and where it doesn't.
A fit
Not a fit, and we'll say so
- Seed stage with no assurance budget. Hire the engineer instead. We'll still be here at Series B.
- You want a bot leaving comments on every pull request. That's a different product.
- You want a certificate, a badge, or a logo for a website. We don't issue those.
- Nobody can say what the path is supposed to do, and nobody will be free to decide.
- The component is a prototype scheduled for a rewrite. Audit the rewrite.
- You need security testing specifically. Security firms audit whether your software can be broken into. We audit whether it works. We work next to pentest, SAST, fuzzing, and bug bounty, and we don't replace them.
Assurance is bounded: within a declared scope, for declared behaviors, with evidence commensurate to the consequence of failure. Outside the declared scope we make no claim, and the methodology states those limits in full.
What procurement and your staff engineers ask first.
| Question | Answer |
|---|---|
| Do you need access to our private source code? | Open-source and public components need no access. For private code we countersign your mutual NDA before details, and for sensitive repositories the audit can run inside your own CI so the code never leaves your infrastructure. Our Trust page has the data-handling detail. |
| How do we know this isn't AI-generated bug spam? | Tooling runs the wide pass. A named reviewer validates every finding before it reaches you, each finding ships with a reproducer that is red on your current main and green once the behavior is fixed, and the report includes the candidates we investigated and dismissed. If a delivered finding fails its own reproducer on the scoped tree, we pull it. |
| What do we actually get? | An evidence corpus in your repository: the requirements your architects approved, a known-issue register in plain YAML, one runnable reproducer per finding, regression tests for the findings you fix, and an audit gate that runs without us. Plus the findings report and a live walkthrough, split for executives and for engineers. |
| Is the engine itself something we can inspect? | Proof is our own audit engine and it stays proprietary: it holds the requirements model, drives the verification chain through MC/DC and formal property checks, and produces the corpus. The instruments around it are public, and the tools page says which is which. |
Bring one path you can't afford to be wrong.
Tell us the component, the trigger, and how access would work. The first reply is a scoping conversation about that component, not a pitch deck. If the fit filter above rules you out, say so in the message and we'll tell you straight.
Proof is built by ProbeLabs and led by Leonid Bugaev, author of GoReplay and jsonparser, who has run engineering for enterprise API infrastructure.
Don't send secrets or private source code through this form. What you submit is used for scoping and follow-up; see Trust.