The software intent graph

A living model of what your software must do.

Proof connects components, requirements, dependencies, hazards, issues, changes, defects, code, documentation, and evidence into one graph that stays synchronized with the software it describes. Every object in it is served to your coding agents over MCP.

Explore public Proof Open the live map ↗ seeded showcase branch; read the labels first

Proof, working · the film

Watch Proof work

The model

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.

01 Intent

Software intent, made explicit

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.

One requirement open in the Proof portal. The identifier SYS-REQ-012 sits beside a System chip and a Review chip. Below it the sentence: 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. A 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 it compiles to, and the rationale with its tags. — The object, in the product. One jsonparser requirement: the sentence, its owning component, its compiled formula, and the tabs that open its evidence. The chip beside the identifier reads **Review**: a candidate, not an approved requirement, stated on the object itself.

All four captures are one run of the public jsonparser portal, 3 August 2026, on the showcase branch proof-demo (our probelabs/jsonparser fork, not buger/jsonparser), which carries seeded demonstration issues. The finding counts in these screens belong to that branch, not to the register on master. Nothing is staged, nothing is recoloured. What the seeding means →

02 Ownership

Components own responsibilities

A component is the unit of ownership. It is the part of the system a team can point at and answer for: a parser, a scheduler, a billing path.

Every requirement, every known issue and every change record belongs to exactly one component. Ownership is recorded, not inferred, so “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.

The Proof portal map for jsonparser in Architecture view. A legend explains that solid arrows are interface contracts, dashed arrows are refinements, node colour is risk, and node size is the number of requirements a component owns. One component node sits on the canvas: parser, with 123 requirements, 22 open and 16 resolved. — 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. Public proof’s dashboard reads 10 open for the same run; both headers read 36 findings. The three counts scope differently and none sums to another: the portal’s own behaviour, and why we point you at the register, not a number.

03 Dependency

Requirements depend on requirements

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.

Sources·specs/stakeholder/requirements/·specs/system/requirements/

The same pair, step by step →Blast radius, on a worked example →

The Proof portal map in Focus view, rooted at one requirement. A control offers three readings of the same neighbourhood: Neighbours, What this affects, and What this rests on. 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. — 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 is the whole argument: **what this rests on** up, **what this affects** down.

04 Change

Every change carries its evidence

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.

Change and defect lineage in full →

05 Invalidation

The graph invalidates itself

Software knowledge becomes dangerous when it silently goes stale. When code, a requirement or a document changes, Proof 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.

Watch a change travel →

06 MCP

The whole graph, served over MCP

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 served over MCP, the protocol coding agents already speak.

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 is a candidate until it is approved at the assurance level you set. The levels you reserve wait for a named person; below them the agent may approve its own work, on the record.

How agents work against the graph →Connect your agent, step by step →

07 Custody

The graph lives with the customer

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.

08 Install

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 one costs less than the first, because the graph it joins already exists.

What the first installation leaves behind

approved requirements
intent graph
hazard analysis
executable findings
change and defect evidence
agent access
CI gate

The Audit checks page of the Proof portal. Counters across the top read 167 total checks, 148 passing, 2 informational, 4 skipped, 9 warnings and 1 error. Below them a list headed All checks, 13 need attention, explains that each row leads with its status and that 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. — The gate, in the product. 167 checks: 148 passing, 9 warnings, one error, needs-attention sorted first. The first row is a gating check and reads **Fail** — the screen an installation leaves behind, and this run does not pass.

The Continuous Correctness Audit is how the first component gets installed. Proof is what stays afterwards.

See the full engagement → Explore public Proof →