A refund never exceeds the captured amount.
Approved by
Alice · Payments
Implementation
refund.go:82-104
Evidence
TestRefundNeverExceedsCapture
Hazards
3 analyzed
Known issues
1 resolved
Depends on
SW-REQ-012SW-REQ-018
Requirements that test themselves.
Proof turns what your software must do into executable requirements that stay aligned as the system changes.
public on buger/jsonparser123 requirements approved
One requirement
A requirement isn't documentation anymore.
In Proof, a requirement is a living object connected to what implements it, what proves it, what depends on it, and what could break it.
Seven relations
depends on REQUIREMENT implemented by CODE described by DOCS verified by TESTS challenged by HAZARDS informed by KNOWN ISSUES supported by EXECUTABLE EVIDENCE
Proof turns software intent into a living, executable graph connecting requirements, code, documentation, hazards, issues and evidence.
Two graphs
Your code has dependencies. Your intent does too.
See the blast radius before you change the code.
Code graph
3 nodes · one kind of edge
Proof
5 nodes · four kinds of edge
A code graph tells you what calls what. Proof tells you what depends on what being true.
Blast radius
Change this. What else did you change?
Before changing the implementation, Proof can show the promises potentially affected by the change.
Select a requirementfour of them are live in this figure
Blast radiusREQ-042
3 requirements · 2 components · 4 tests · 1 document · 2 hazards
Self-invalidating
The graph knows when it needs to be proven again.
Knowledge about software becomes dangerous when it silently goes stale. When implementation, requirements or documentation change, Proof identifies the evidence and intent that may no longer be valid.
- 14:02proof verifySW-REQ-042 proven
- 14:31git push 821ca2SW-REQ-042 needs proving again
- 14:33proof verifySW-REQ-042 proven again
Fig. 05 · One requirement and the three things attached to it. The push changes the code, so the requirement and everything attached to it stops counting as proven until verification runs again.
It doesn’t just remember what was true.It knows what needs to be checked again.
Humans and agents use the same graph to understand what the software promises, change it safely, and prove those promises still hold.
Agents
Your agent shouldn’t have to rediscover your system every time.
Every session starts from nothing. The agent reads your files and infers what matters, when your team already decided what must stay true.
Fig. 06 · The agent stops guessing at the first question and starts at the seventh.
One question, one session
agent session
jsonparser · set.go
~/src/jsonparser
youI’m changing Set() to support nested arrays. What can this affect?
Proof
Relevant intent
- KI-3Set() must preserve sibling values
- KI-7Nested updates preserve parent structure
- KI-11Array indexes cannot mutate adjacent entries
Blast radius
4 requirements · 3 implementation areas · 7 tests · 2 hazards
Known issue
KI-3 was previously violated.Reproducer available →
set.go:212 · TestSetSibling
Agent work
What the agent does with it.
The graph is not something the agent reads once. It answers a different question at each step of the work.
-
Understand
Navigate by intent, not files.
Ask what a subsystem promises, why a behavior exists, and what depends on it.
-
Change
Know the blast radius before editing.
Give the agent the requirements, hazards and historical issues surrounding the change.
-
Fix
Start from executable evidence.
Findings include reproducers, so the agent can observe the failure before touching the implementation.
-
Verify
Prove the change, not just the patch.
Run the evidence around the underlying requirement and reconsider anything invalidated by the change.
Fig. 07 · The same graph at every step. Verify is the step that puts something back.
The queue
Give the agent the evidence, not the bug report.
Proof changes the quality of the work entering the engineering queue. Instead of asking an engineer or agent to investigate an ambiguous report, it can start with the requirement, context and executable evidence.
Traditional
BUG #481
“Sometimes nested arrays seem to return wrong values.”
- reproduce
- understand
- intended behavior
- related code
- regression
- blast radius
- test
- fix
Engineerstarts by finding out
Proof
FINDING #481
“Set() must preserve sibling values.”
KI-3 · violated
- RequirementSW-REQ-118
- Intent graph4 requirements linked
- Hazards2 analyzed
- Relevant codeset.go:212-260
- ReproducerTestSetSibling
- Expected behaviorstated in the requirement
- Blast radius7 tests
·3 areas
Agentreproduce → change → verify
Both columns are the same defect. The difference is what the work starts with.
Public receipt
We ran it on real software.
Everything below is public. You can run it again.
Real public repository
buger/jsonparser, a 5,600-star Go library, more than ten years in production.
123
Requirements approved
7
Defects fixed upstream
1
Miss published
Each finding is a test that failed on main.
Not an opinion, not a warning, not a suggestion.
Finding
Requirement
Result
KI-1
A boolean is only true for the exact token true.
KI-2
A unicode escape is rejected unless four hex digits follow it.
Fixed upstream #271
KI-3
Set() on an array-index path never drops a sibling value.
KI-4
An integer too large for int64 returns an error and never wraps.
Fixed upstream #279
KI-5
A UTF8 decode never reads past the length the config declares.
Fixed upstream #283
KI-6
An empty array returns the empty sentinel and never a nil slice.
Fixed upstream #287
KI-7
EachKey visits a key once, even when the document repeats it.
Seven promises, seven failing tests, seven merges in the project's own repository.
Don't take our word for it.
We publish the promises we get wrong on the same register as the ones we get right. That is the only way you can check us.
How it works
How Proof builds the graph.
Proof reads your code and writes down the requirements it already keeps. Your engineers approve each one, and every approved requirement gets evidence that can fail.
01
Recover
Proof reads the implementation and writes down the requirements it already keeps, with the code and the tests that carry each one.
02
Approve
Your engineers read each requirement and approve it. An agent cannot approve its own requirement.
03
Prove
Each approved requirement gets evidence that fails when the requirement breaks. Evidence is a test, not a note.
04
Gate
The gate runs in your CI on every commit, and it re-checks whatever the change invalidated.
Proof also counts coverage the strict way: every condition inside a decision has to be shown to change the outcome on its own. Engineers call that MC/DC, and it is why a green suite is not the same as a proven requirement.
Accountability
Who checks the checker.
Machines check everything, every time. People decide what a machine must not decide alone. This limit is written in the configuration. You can move it.
Agents
Run every check, on every commit. The quantity is more than a person can read.
A person
One person validates each finding before it reaches you. People sign the promises, the bar, and our misses.
Your engineers
Sign the promises. Each item an agent writes has a draft mark. An agent cannot approve its own requirement.
Fig. 08 · CI is green in the two pictures. The second picture is possible only after the promises are written down.
The whole method →Our misses are published. MISS-001, signed by Leonid Bugaev.
Delivery
How teams start.
You do not install Proof and hope. We run the first pass with you on one component, and you keep everything it produces.
The first engagement
01 · one component
We pick one component that carries real risk. Proof recovers its requirements and brings your engineers the first register to read.
02 · your engineers approve
Nothing counts until a person approves it. We sit with your engineers for the first pass, so the bar is yours and not ours.
03 · the gate goes in
The gate runs in your own CI on every commit. Findings arrive with the test that fails, and a person has validated each one.
What you keep
The requirements
Plain files in your repository, under your licence, approved by your engineers.
The evidence and the register
Every finding has a test that fails on your current main, and the register records what was proven and when.
The graph and the gate
Your engineers, your CI and your agents read the same graph. If we stop work tomorrow, all of it keeps running.
We deliver this as a Continuous Correctness Audit: one component, one register, one gate, with a fixed scope agreed before we start. Read what the first weeks look like, week by week, on the onboarding page.
Final receipt
Set() replaces one value and changes nothing else.
This promise was implicit for years. Proof made it explicit, found the violation, produced the failing test, and the maintainer fixed it upstream.
Prove your software does what you promised.
What requirements are hiding in your codebase?
We run Proof on one public project each quarter, at our own cost. There is no invoice and no follow-up.
Leonid Bugaev · founder
signs the promises we publish, and the ones we miss