Proof connects requirements to their dependencies, code, hazards, issues, changes, and evidence—so it can find where implementation breaks intent, show the blast radius of every change, and name what must be re-proven.
Proof is AI-native software assurance for changes made by humans and coding agents. The Software Intent Graph is the product underneath. People and agents work against the same graph. Proof attaches code, tests, and evidence to the approved intent and keeps the attachments current.
One component, and everything Proof records about it.
The object model · Nothing in this figure is verified, stale or violated. It is the shape of what Proof records, before anything has been claimed about it.
01Intent
Model what must stay true.
Requirements become queryable objects with owners, dependencies, hazards, and executable evidence.
Every system already has intent. It is scattered. Some of it is implied by the code, some of it is buried in a ticket system, and the rest is carried by the people who were in the room when the decision was made.
Proof writes it down as objects. A requirement states what the software must do, in one sentence with a recorded approver. It names the evidence that keeps it true, and that evidence runs.
Fig. 01 · Three sources become one object. None of the three on the left can be queried, and only one of them runs.
The object, in the product. One jsonparser requirement, SYS-REQ-012, sits beside a System chip and a Review chip: not an approved requirement yet, stated on the object itself. The sentence reads “when ParseBoolean receives a valid raw boolean token, the parser shall return the corresponding Go bool value.” A row of fields gives priority, type, category, owning component, assurance level and worst open finding. The tab strip reads Specification, Rationale, Verification, Obligations, Formula evidence, Its place, Trace evidence, Impact and Discussion. Open below it are the description, the FRETish formula the sentence compiles to, and the rationale with its tags.
One run of the public jsonparser portal, 3 August 2026, on branch proof-demo of our fork probelabs/jsonparser. Its open findings are seeded demonstrations; the real register is on buger/jsonparser master. What the seeding means →
02Ownership
Give every responsibility an owner.
Every requirement, issue, and change belongs to a component that a team can answer for.
A component is the unit of ownership. It is the part of the system a team can point at: a parser, a scheduler, a billing path.
Every requirement, every known issue and every change record belongs to exactly one of them, and the graph records that ownership on the object. “Who is responsible for this behavior” has an answer you can open.
Fig. 02 · A component is a complete unit of intent. That is why Proof can be installed on one of them and still be useful.
Ownership, in the product. One node per component, sized by the requirements it owns; jsonparser has one component, so one node and no contract edges. The legend reads: solid arrows are interface contracts, dashed arrows are refinements, node colour is risk, and node size is the number of requirements a component owns. The one node is parser, and each number under it counts a different object: 123 requirements owned by the component, 22 open finding-to-requirement links, and 16 resolved finding-to-requirement links. The map counts by links, so one known issue that names three requirements is one record on the Public proof dashboard and three links here; that dashboard reads 10 open known-issue records for this run. The 36 findings in the project header count a third population again: 23 finding records plus 13 checks needing attention. Every number in this caption is read off the capture above, taken 3 August 2026; the live board moves.
03Dependency
See what depends on it being true.
Requirements are not a flat list. A software requirement rests on a system requirement, which rests on something a stakeholder asked for. A requirement also carries hazards: the outcomes that must not happen when it fails.
Proof does not record what calls what. It records what depends on what being true. Two functions that never meet in a stack trace can still rest on the same promise, and the graph knows it.
Fig. 03 · One pair from the open-source jsonparser project, with both specification folders linked below. The hazard box is the slot the model gives every requirement, not a record from that project. The same edge is read in both directions. Upward it is what this requirement rests on. Downward it is what a change to it can reach.
The same edge, both ways, in the product. Rooted at the requirement from section 01, not the pair drawn above, the map reaches its source, tests, document and component. The control at top left offers three readings of the same neighbourhood: Neighbours, what this affects, and what this rests on. That control is the whole argument: what this rests on up, what this affects down. The focused node is the requirement about ParseBoolean, and the header reads 12 of 12 nodes. Edges labelled implemented by, verified by, documents, satisfies and belongs to reach out to parser.go, the README, five test files, the parser component and a second requirement.
04Violation
Find where implementation breaks the model.
Proof checks the implementation against approved intent and turns confirmed violations into reproducible issues.
The check has something exact to check against. An approved requirement names the obligations that must hold for it. The annotated source claims to carry it. The evidence bound to each obligation runs against the current code, and the result is recorded against that revision of the graph.
When the evidence contradicts the approved sentence, Proof files a known issue on the owning component. It carries the requirement that broke, what the code did, and a command you can run yourself. While the bug is live that test asserts the broken output; it is flipped at the fix, so a regression trips it either way.
What the check compares
01the approved requirement, and the obligations it names
02the annotated code that claims to carry it
03the evidence bound to each obligation
04the run, against this revision of the code and the graph
05the verdict: verified, evidence stale, or violated
One violation Proof filed, on a public project
KI-3was violated
KINDknown issue · fixed on master
VIOLATED INTENT
SYS-REQ-009 · approved, with the reviewer named in the file
WHAT THE REQUIREMENT PROMISED
Set must update the addressed JSON value without corrupting unrelated structure.
WHAT THE CODE DID
Set with an array-index path component under an object parent produced malformed JSON and returned it with a nil error.
The four known issues Proof filed against jsonparser master are all closed, KI-3 among them. That is why this one reads end to end in public: the finding, the reproducer, the fix and the evidence kept afterwards are files in the repository. The open findings in the portal captures on this page belong to the seeded showcase branch, and the badge on each capture says so.
A commit says what text moved. It does not say why the behavior moved, or what still holds afterwards.
In Proof a change is a record. Features, behavior changes, refactors and fixes are one object with a different kind, and each one arrives with the evidence that made the result acceptable.
What a change record carries
01why the behavior changed
02which component owns it
03which requirements were introduced, changed, or affected
04the implementation diff
05documentation changes
06blast radius
07tests and other evidence
08review and approval
09final verification state
Three words this page uses precisely
known issue
A problem that is not resolved yet. It carries the violated requirement, the affected component, and a reproducer that runs.
defect record
The evidence-bearing history that exists after a fix is verified. It keeps the originating issue, the original reproducer, the fixing change, the root cause, and permanent regression evidence.
change record
The shared model across features and fixes. Every kind of change uses it, so the history of a component reads as one sequence.
A passing reproducer proves the known instance is gone. The wider class stays open until broader evidence arrives, and Proof keeps the two apart.
Software knowledge becomes dangerous when it silently goes stale. Proof is a self-invalidating graph: when code, a requirement or a document changes, it identifies the relationships and the evidence that may no longer be current.
Stale is not false. Proof does not declare the requirement wrong. It withdraws yesterday’s confidence, and it names the obligations that have to be reviewed or rerun before the claim stands again.
✓VERIFIED
The evidence ran against this version of the code and this version of the graph, and it passed.
?EVIDENCE STALE
Something it rests on moved. The result is not withdrawn as wrong, it is withdrawn as unproven, and it has to be earned again.
✗VIOLATED
The evidence ran and it failed. A known issue is attached, with the reproducer that shows it.
Nobody has to remember which document went out of date. The graph carries the dependency, so it can raise its own hand.
Everything on this page is a queryable object. Components, requirements, dependencies, hazards, known issues, change records, defect records, reproducers, verification obligations, evidence — the whole intent graph is readable over MCP, the protocol coding agents already speak.
Agents read the graph through MCP. Proposed changes and new evidence move through the customer’s repository and approval workflow.
There is no human edition and no machine edition. A person opens the portal; Claude Code, Codex, or any MCP client queries the same objects, with the same relationships and the same evidence attached.
A person opens
the requirement, and what it rests on
the hazards it carries
the code and documentation that implement it
the evidence that keeps it verified
every change that has touched it
An agent receives, over MCP
the requirements in scope for this edit
the blast radius of the edit
the obligations that must pass before the work is complete
the reproducer, when a known issue already exists
the same change history, as structured context
One question, answered from the graph
>what does the parser promise about ParseBoolean?
SYS-REQ-012
“When ParseBoolean receives a valid raw boolean token, the parser shall return the corresponding Go bool value.”
Its place
implemented by parser.go · verified by five test files · documented in the README · owned by the parser component
Status
Review — a candidate, and the object says so
The same requirement, map and chip the captures above show, as an agent receives them. The film on this page shows it running live.
What an agent writes lands at draft, and out of the box the same agent can approve it at any assurance level, with the record naming the agent and the level it ran under. Reserving a level for a named person is opt-out and it is one setting: agent_autonomous_for: all: false, plus the levels you delegate. An empty list keeps every approval human.
The graph is not a dashboard you rent. It lands in your repository as plain files, under your licence, versioned with the code it describes.
The evidence is executable. Tests, properties and reproducers run on your runners, with your secrets, and the gate that blocks a bad merge is a step in your CI.
Fig. 04 · The same tree, on disk. Every object in the model above is a file you already own.
You keep them if we stop. Nothing in the graph needs us in the room to run.
09Install
Install it on one component.
You do not install Proof across a company. You install it on one component that matters, with the engineers who own it.
One component is enough to be useful, because a component is a complete unit of intent. The second component starts from an existing graph and will usually cost less to install than the first.
The gate, in the product. The counters read 167 total checks: 148 passing, 2 informational, 4 skipped, 9 warnings and 1 error. The list below them is headed All checks, 13 need attention. Each row leads with its status, and the Gate or Advisory tag is the enforcement level rather than a result. The first rows are failures: a high severity reproducer grade check tagged Gate and marked Fail, then obligation evidence complete marked Fail, then two warnings. This is the screen an installation leaves behind, and this run does not pass.
Three ways to begin
one real change
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
Ten unresolved items from one component. Every accepted item receives an explicit, evidence-backed disposition, and none returns as the same ambiguous ticket. Bring ten items →
one consequential component
The Continuous Correctness Audit, about four weeks, is the component-level install this section describes. See the full engagement →
The Continuous Correctness Audit is how the first component gets installed. Proof is what stays afterwards.
