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. The same requirement is set out in full in the next section.
Proof builds a living graph of what your software must do, what depends on it, and what proves it. The same graph guides your engineers and coding agents.
In Proof a requirement is an object in the system,
not a paragraph in a document. It names its component, the intent
it rests on, the code that implements it, the tests that verify
it, the obligations it still owes, and the defects that changed
it.
A code graph tells you what calls what.Proof tells you what depends on what being true.
Select a component, requirement, issue, or change. Proof
shows the intent it rests on, the promises downstream, and the code,
tests, documents, and contracts that may need to be reconsidered.
Code graph
3 nodes · one kind of edge
Proof
6 nodes · five kinds of edge
Fig. · Example service · The same
system, seen two ways. Example. Colour carries state: green is verified
knowledge, the hazard branch is marked as a hazard, and grey is structure
with nothing proving it.
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
Fig. · Example service · One
requirement, walked out to everything that rests on it. The PAY-*
service is invented for this drawing and the counts are
illustrative.
A commit says what text moved. A Proof change record
says why the behavior moved, which components and requirements were
affected, what code and documentation changed, and which evidence made
the result acceptable.
Four kinds of change record. Two of them are shown below.
CHANGE-1042
Verified
KINDfeature
INTENT
Support nested array updates.
COMPONENTS
parser
REQUIREMENTS
2 added ·3 affected
IMPLEMENTATION
4 files
DOCUMENTATION
1 document updated
EVIDENCE
8 tests ·2 properties · hazard review
APPROVED BY
maintainer
ExampleHand written for this page. The
identifier, the counts and the approver are illustrative. The record beside it is real
and links to its file.
DEFECT-260726-MFPACovered by requirementthe record’s own status: the instance is fixed and the obligation now sits on the requirement, so the class is not declared closed
KINDdefect fix
ORIGIN
Known issue KI-3
VIOLATED INTENT
SYS-REQ-009
REPRODUCER
pins the break on the affected revision
FIX
parser.go
INSTANCE
fixed
DEFECT CLASS
evidence attached / status explicit
REGRESSION
permanent test retained
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.
Software knowledge becomes dangerous when it silently goes stale. When code, a requirement, or documentation changes, Proof identifies the relationships and evidence that may no longer be current.
It does not automatically declare the requirement false. It withdraws yesterday’s confidence until the affected obligations are reviewed or rerun.
Change recordCHANGE-1042
ExampleThe record id and its fields are hand written for this page. The state change they illustrate is the real mechanism.
EVIDENCE REQUIRED
VERIFIED
Fig. 05 · 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.
Proof does not just remember what was true.It knows what must be checked again.
Agents
Give your agents the same understanding.
Your agent shouldn’t have to rediscover your system every time. Through MCP, coding agents query the same components, requirements, dependencies, hazards, issues, changes, reproducers, and verification obligations that your engineers see.
Code tells an agent what the system does.Proof tells it what the system must not stop doing.
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; the counts in this session are illustrative.
Agent fix loop
Give the agent the evidence, not the bug report.
A normal issue asks the agent to reproduce the problem, reconstruct the intended behavior, find the relevant code, decide what else could break, and invent a completion test.
A Proof issue arrives with the violated requirement, blast radius, hazard context, reproducer, relevant code, and the evidence required to close it.
NORMAL ISSUE
“Set sometimes corrupts nested data.”
01investigate
02reproduce
03infer intent
04find code
05guess blast radius
06write test
07fix
08hope
PROOF ISSUE
arrives with
requirement
component
hazards
blast radius
reproducer
required evidence
01agent runs failure
02agent changes code
03Proof reruns obligations
defect record is created
No reproducer, no finding.
Both columns are the same defect. The difference is what the work starts with.
The agent begins at the fix loop,not at the archaeology loop.
Compounding knowledge
Every change makes the next change safer.
Features, fixes, incidents, misses, reproducers, approvals, and evidence do not disappear into old pull requests. They remain attached to the intent they changed.
The next engineer—or the next agent—starts with the accumulated model of the system instead of reconstructing it from raw code.
One lap. Every step leaves a line open, so the bundle is one line wide at the top and seven wide at the bottom. The band on the left carries all of it back to the start, which is why the next lap begins with more than this one did.
We started with jsonparser, a decade-old Go library we could not hide from. Formalizing its behavior produced 123 requirements, 28 of them approved so far, and the review found six defects that were then fixed upstream. Two further defects escaped the review, with 100% MC/DC on the affected code. The postmortem that names both is public, so the register carries two.
We published the miss, the proof gap, the reproducer, and the fix.
123
requirements
6
defects found and fixed upstream
2
misses published
Each finding carries a test you can run.
Not an opinion, not a warning, not a suggestion.
One finding, end to end
01requirement
SYS-REQ-009approved
Set() replaces the addressed value, creates a type-consistent path, or returns KeyPathNotFoundError. A person who owns the code approved that sentence before any code was judged against it.
An array-index path component under an object parent produced malformed JSON output, and Set() returned it with a nil error. The caller had no signal that the bytes could not be parsed again.
One executable test, pinning the failure while it was live: it asserted that the output was not valid JSON. The file carries // Verifies: SYS-REQ-009 and // Reproduces: KI-3 on one screen, so it says which promise it proves and which failure it pins.
The record names the code that carried it and dates it to the library's first release, so every revision before the fix is affected. The requirement's own history stamps the window: verification failing on 26 July 2026, passing again the next morning.
Set() now replaces a mismatched container with the type the path expects, so every non-erroring call returns valid JSON. The defect record names the root cause, the obligation it added, and the regression test.
The same test as step 03, still in the suite, flipped at the fix: it now asserts that every cross-type call returns valid JSON. The obligations on the requirement run against it again.
The same sentence as step 01, re-approved by the engineer who owns the code once the hardening was attached, with the defect named in the record as the reason for the re-approval.
Seven steps, seven records, and each one is a file in the public repository. The requirement that opens the chain is the requirement that closes it.
The register
Six defects, four records, eight defect files.proof/problem-reports/ holds eight defect records and every one is fixed on master. Two of the eight were reported by outside contributors, credited by name in the CHANGELOG, which leaves six the review found by itself. The register below shows four records because it lists known issues, not defect files, and KI-2 and KI-4 were fixed later, in v1.6.0. The two published misses are the two credited outside, so they sit beside the six rather than inside them.
FindingWhat was wrongResult
KI-1
An empty key path component panicked in the key search instead of returning an error.
Four issue records on the project's master branch, every one of them status: fixed, every one of them carrying the command that reproduces it. The wider defect history, including the two misses below, sits beside them in proof/problem-reports/.
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.
Proof checks the requirement before it judges the code, connects the claim to implementation and evidence, analyzes how it can fail, and leaves the resulting checks in your CI.
01
APPROVE THE INTENT
Engineers sign what the component must do.
02
ANALYZE THE OBLIGATIONS
Formal semantics and hazard analysis define what evidence is needed.
03
BIND THE EVIDENCE
Code, documentation, tests, proofs, reproducers, and coverage attach to the claim.
04
RE-EARN THE RESULT
Changes invalidate affected evidence and the gate runs again.
Instruments
FRETish · Kind2 · Z3 · hazard analysis · MC/DC
property tests · fuzzing · executable reproducers · CI gate
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 and the bar, and decide that a miss gets published. The published postmortem carries no personal signature, and we say so where we publish it.
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 go on the same public register as the findings, with the proof gap named and the reproducer attached. Read the register ↗
Installation
Install Proof on one consequential component.
The Continuous Correctness Audit is the fastest way to build the first production-grade intent graph inside your software. We recover and formalize the requirements, your engineers approve them, and Proof binds the component to its hazards, code, documentation, issues, changes, and evidence.
Continuous Correctness Audit
The installation
Scope
ONE COMPONENT
roughly four weeks
fixed fee after scoping
What you keep
approved requirements
intent graph
hazard analysis
executable findings
change and defect evidence
agent access
CI gate
You finish with the graph, the evidence corpus, and a gate in your CI. Everything that runs stays yours.
The audit is how Proof gets installed. Proof is what stays.