AI-native software assurance

Ship more changes without lowering the bar.

Proof reduces the work between a change and a trusted release. It keeps the intent, dependencies, evidence, and history connected, so humans and coding agents know what the change affects and what must be proven before it can be accepted.

Watch Proof work Open a real finding Bring one real change →

The moving graph behind this headline is drawn from the public jsonparser project. It centres on the requirement SYS-REQ-009. Around it are the requirements that requirement rests on, the source files and test files that implement and verify it, the change that touched it, and the known issue and defect record that strengthened it. Every identifier in the graph is real and can be checked in the repository.

Disappeared work

Stop starting from zero on every change.

Without Proof

Reconstruct intended behaviour
Search tickets and old pull requests
Find the responsible component
Reproduce the failure
Map the blast radius
Choose the relevant evidence
Explain the risk to reviewers
Rediscover previous failures
Repeat the same work next month

With Proof

INTENTalready connected
HISTORYalready attached
BLAST RADIUSqueryable
REPRODUCERSretained
EVIDENCE REQUIREMENTSexplicit
PREVIOUS FAILURESreusable

Proof is designed to remove the repeated setup work around a change: reconstructing intent, recovering history, reproducing known failures, mapping impact, and deciding what evidence is required.

How Proof connects a change →

The graph

Live from the jsonparser audit

Change one thing. See what else moves.

Proof does not inspect a bug or code change in isolation. It connects the requirement behind it to dependent requirements, the code and documentation that implement it, the tests and evidence that verify it, previous failures, hazards, and external obligations. Change one thing, and Proof shows what else may need to change or be proven again.

Open live requirement in the portal seeded product demo; read the labels first

SYS-REQ-009

Approved

When Set is called with a provided path, the parser shall either replace the existing addressed value, create a type-consistent missing path and return the updated JSON document, or return KeyPathNotFoundError when the requested mutation path is not usable for the provided input.

Component: parser
Parent requirement: STK-REQ-005 Review approval is per requirement: the parent’s state does not gate this one
Verified by: 12 test files
Defect history: 3 records name it, latest DEFECT-260727-WWWY

SHORT FORM — the same requirement carries its owner, obligations and source files in the portal.

A code graph tells you what calls what. Proof tells you what depends on what being true.

Code graph

3 nodes · one kind of edge

Proof

6 nodes · five kinds of edge

Fig. 01 · Example service · The same system, seen two ways. Colour carries state: green is verified knowledge, the hazard branch marks how the requirement could fail, and grey is structure with nothing proving it.

How the model is built →See the graph model →

See the blast radius before you touch the code.

Change this. What else did you change?

Select a requirementfour of them are live in this figure

If this changesPAY-042PAY-18PAY-61PAY-94

5 files · 13 tests · 1 parent requirement · related obligations

2 files · 5 tests · 1 parent requirement · related obligations

1 file · 3 tests · 1 parent requirement · related obligations

2 files · 5 tests · 1 parent requirement · related obligations

Fig. 02 · Example service · One requirement, walked out to everything that rests on it. The PAY-* service is invented, and so are its counts.

Explore the live graph ↗ seeded product demo; read the labels first

Agents

Let agents own work you could not reliably delegate before.

Through MCP, the agent receives the requirement, its dependencies, history, hazards, the reproducer, the blast radius, and the verification obligations before it edits a line. That widens what a team can delegate: fix-ready bugs first, then the changes that used to need someone who already knew the history.

Code tells an agent what the system does. Proof tells it what the system must not stop doing.

The connection

agent session proof · jsonparser

~/src/jsonparser

I need to change Set() for nested arrays.

What can this affect?

Proof

RELEVANT INTENT

SYS-REQ-009 · SYS-REQ-069 · SYS-REQ-110

BLAST RADIUS

1 component · 3 files · 8 tests · 3 hazard obligations

HISTORY

1 related defect record · 2 known issue classes

REQUIRED BEFORE COMPLETION

reproducer
boundary obligation
nested-mutation property
documentation review

answered from the graph

Fig. 03 · The answer is not a file list. It is the intent the change touches, what the change can reach, what already went wrong here, and the evidence the change has to produce before it can be called done. The requirement identifiers are real and published.

Point your agent at the live jsonparser graph, over MCP →

Acceptance

The agent writes the change. Proof protects the agreement.

Approvals are bound to requirement content, so editing an approved requirement marks its approval stale. Reproducers and regression evidence are checked by the gate on every run. When the code that evidence rests on changes, the evidence goes stale until it runs again, so the implementing agent cannot quietly weaken what “done” means.

Proof does not declare the requirement false when something moves. It withdraws yesterday’s confidence until the affected obligations are reviewed or rerun.

Change recordCHG-260728-H6ER

REVIEW REQUIRED

20 REVIEWED

Fig. 04 · One requirement and the three things attached to it, before the change, at the moment the change lands, and after verification runs. The record stays open until the affected obligations are reviewed or rerun.

Public audit evidence The three panels are drawn to show the arc a record moves through. The record beside them is real: CHG-260728-H6ER is the v1.5.0 feature change on the public jsonparser corpus, and twenty entries in its branch impact-review file name it, each carrying its reviewer and the date it was reviewed. The record is opened field by field on the changes page.

Proof does not just remember what was true. It knows what must be checked again.

Compounding

Fix the issue. Keep the lesson.

The unresolved issue closes into a verified defect record containing the original failure, fixing change, regression evidence, and explicit status of the wider defect class. The lesson remains attached to the intent it changed.

KI-3

Open · 26 July 2026

KINDknown issue · jsonparser · component parser

TITLE

Set with array-index path component under an object parent produces malformed JSON output.

VIOLATED REQUIREMENTS

SYS-REQ-009 · SYS-REQ-110 · SYS-REQ-112

the approved promises this breaks

RELEVANT CODE

parser.go createInsertComponent, line 756 · Set, lines 1018-1038

where the invalid bytes are written, and where the path was never rejected

SEVERITY

high · basis: reproducer

the basis field records what earned the rating

BLAST RADIUS

3 approved requirements · 1 public API, Set · risk: data integrity

the caller gets invalid bytes back with a nil error

REPRODUCER

go test -v -run TestSetArrayIndexUnderObjectMalformedJSON_KI3 ./...

runs on the affected revision and shows the invalid output

REQUIRED BEFORE IT CAN CLOSE

the tripwire test flips to assert valid JSON · a malformed_input obligation attaches to SYS-REQ-009 · the wider defect class carries an explicit status

agreed on the record before anyone writes the fix

Real record · Read off proof/known-issues/KI-3.yaml on the public jsonparser project, in the state it held on 26 July 2026, while the bug was live. KI-3 was fixed the next day. The file, the defect record and the reproducer are all still on master, and you can run the test today.

01OPEN ISSUEthe known issue, with its reproducer
02FIXING CHANGEthe code that answers it
03INDIVIDUAL EVIDENCEthe reproducer passes and stays in the suite
04CLASS-LEVEL EVIDENCEobligations, sibling sweep, hazard and blast-radius checks
05VERIFIED DEFECT RECORDthe failure, the fix, the evidence, and the class status

One passing reproducer can settle the known instance. Closing the wider class takes broader evidence, and the record says which of the two it has.

DEFECT-260726-MFPA

Covered by requirement

KINDdefect fix

ORIGIN

Known issue KI-3

the known issue that opened this record

VIOLATED INTENT

SYS-REQ-009

the promise this defect broke

REPRODUCER

pins the break on the affected revision

FIX

parser.go

INSTANCE

fixed

DEFECT CLASS

evidence attached / status explicit

the class stays open until sibling evidence lands

REGRESSION

permanent test retained

Real record · This is what KI-3, the open issue shown above, closed into. Read off proof/problem-reports/DEFECT-260726-MFPA.yaml on master.

Open problems remain known issues. When the fix is verified, Proof creates a defect record using the same evidence-bearing model as any other change. The issue closes; the proof stays.

Fig. 05 · One lap. One line open beside the first step, seven beside the last; the band carries all of it back to the start.

See a change move through Proof →Why the graph gets more valuable →

Public proof

What changed for teams using Proof?

Customer measurements are being collected on every engagement and are not yet published. Until they are, the answer is the public record. It includes the findings Proof later withdrew and the defects its own gate missed.

rsync

Thirty years old, widely shipped across Linux and Unix systems. Audited continuously through the development of the 3.5.0 security release, and still running.

99 findings filed by the audit · 28 later withdrawn in public · 10 present in the code since the first release in 1996

The audit filed 99 findings. The 3.5.0 release shipped 33 security fixes from the combined focused audit, daemon fuzzing, Trail of Bits work, and other external research. Every fix shipped upstream with a CVE ID and a regression test.

Read the rsync audit →Read the release notes ↗

jsonparser

A decade-old Go library, maintained by Proof’s founder, put first on purpose as code we could not hide from. Its whole corpus is on master.

123 requirements · 6 defects found by the review · 2 misses published

The two misses are defects that got past the gate. They sit on the same public register as the findings, with the proof gap named and the reproducer attached.

Read the jsonparser evidence →Open the corpus ↗

On rsync we worked alongside Trail of Bits, through its Patch the Planet program.

We have run Proof on more of the software everyone depends on: google/grpc-go, graphql-hive/router and wundergraph/graphql-go-tools. See what we found and fixed → the public roster.

Customer engagements

Being measured · not yet published

Every engagement records the human work around each change. The north-star measure is active human engineering time per accepted change. Three outcome measures are recorded with it.

human engineering time per accepted change · time to evidence-backed closure · dev/QA rework cycles

After every pilot we ask three questions. What could you reliably do after Proof that you could not before? What work disappeared? What do you trust Proof to do that you would not trust a general coding agent to do alone?

who checks the checker

Machines run every check on every commit. A person validates each finding before it reaches you, sets the bar the promises are judged against, and decides that a miss gets published in public Proof work. You never open a finding that nobody checked.

What “verified” means, in full →

We publish what we withdrew, and what we do not take credit for, beside what we found. That is the only way you can check us.

Don’t take our word for it.

Open the public evidence →

Start

Ways to begin.

Each has a fixed scope and a record you keep.

One real change.

Fixed scope

Bring one consequential change. Proof connects it to the intent it touches and asks only the questions that need an owner’s decision. Your existing coding agent implements against acceptance evidence agreed before the code is written.

You receive the Change record and a measurement of the human work involved.

Bring one real change →

Ten unresolved items.

Fixed scope

Ten unresolved items from one component. Every accepted item receives an explicit, evidence-backed disposition: disproved, duplicate, needs a decision, fix-ready, fixed and verified, deferred, blocked, or class still open.

The promise is that none of them returns as the same ambiguous ticket.

Bring ten items →

One consequential component.

Fixed scope · about four weeks

The Continuous Correctness Audit installs the first production-grade Proof graph on one consequential component. You keep the approved requirements, hazard analysis, known-issue register, change and defect evidence, agent access, and CI gate in your own repository.

Fixed fee after scoping. Everything that runs stays yours.

See the full engagement →

The audit is how Proof gets installed. Proof is what stays.

What work would disappear from your engineering process?

Bring one real change and let us measure it.

Bring one real change → Maintainer? Apply for an open-source audit →

The open-source audit is separate from the paid work: one public project each week, at our own cost, on the maintainers’ schedule. There is no invoice and no follow-up.

Leonid Bugaev · founder
sets the bar these promises are judged against, and publishes the misses from public work on the same register