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.

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

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. Tinted to this page’s palette by a CSS filter; the portal’s own colours are different.

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 a person approved. 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 requirement of the open-source jsonparser project: the sentence, the component that owns it, the formula it compiles to, the rationale, and the tabs that open its obligations, its evidence and its impact. Read the chip next to the identifier: it says **Review**. That is a candidate, not an approved requirement, and the portal states it on the object rather than in a footnote.

All four captures on this page are one run of the public portal for jsonparser, dated 3 August 2026. It is the showcase branch, proof-demo (on our probelabs/jsonparser fork, not on buger/jsonparser), which carries seeded demonstration issues next to the real history, so the finding counts inside these screens belong to that branch and not to the fixed register on master. Nothing in them is staged for this page. 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. Example, hand drawn.

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. The Architecture view draws one node per component, sized by how many requirements it owns. jsonparser is a single-component project, so there is one node and no contract edges to draw between components. The two issue counts on the node are this run’s, on the branch named above. The dashboard tile on public proof reads 10 open for the same run, and the header on both reads 36 findings. The three counts scope differently and none of them sums to another; that is the portal’s own behaviour, not a claim of ours, and it is why we point you at the register rather than at 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. This is the requirement from section 01, not the pair drawn above. Rooted at it, the map reaches the source that implements it, the tests that verify it, the document that describes it and the component that owns it. The control at the top left is the whole argument of this section: **what this rests on** going up, **what this affects** going 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 Access

Humans and agents use the same model

There is no human edition and no machine edition. A person and a coding agent open the same objects, with the same relationships and the same evidence attached to them.

Only the shape of the answer differs. A person reads a requirement. An agent receives the same requirement as structured context before it writes a line of code.

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

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

Agents reach the graph over MCP today, and that interface is expected to change, with the permissions you grant. What an agent writes is a candidate. It is not approved intent until a person approves it.

How agents work against the graph →

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 on this run: 148 passing, 9 warnings and one error, with everything that needs attention sorted to the top. The first row is a gating check and it reads **Fail**. This is the screen an installation leaves behind, and the run we are showing you 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 →