One component, and everything Proof records about it.
Component
the unit that owns behavior
Requirements
what this component must do
Dependencies
the requirements this one rests on
Hazards
what must not happen when it fails
Implementation
the code and documentation that carry it
Evidence
checks and demos for this revision
Issues
known problems, still open
Changes
every edit that moved the behavior
Features
new or changed intent, with its evidence
Defect records
the verified history of a fixed known issue
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 the evidence that keeps them true.
Every system already has intent. It sits in the code, in tickets, and in the people who were in the room.
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. A check, a scenario, or a demo. That evidence runs against this revision.
In the code
a source. It cannot be queried.
In the ticket system
a source. It cannot be queried.
In people’s heads
a source. It cannot be queried.
Requirement
the one object. Only this one runs.
Approved
approved on the record
Evidence
names the evidence it needs
Rerun
rerun on every change
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, still in review. The sentence says what the parser must do. The record names the owner and the evidence that keeps it true.
Seeded demo, 3 August 2026, on branch proof-demo of our fork probelabs/jsonparser. Open findings here are demonstrations. The real register is 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.
Project
parser, scanner, and writer
Parser
the open component
Requirements
owned by the parser
Issues
owned by the parser
Changes
owned by the parser
Scanner
a component of the same project
Writer
a component of the same project
Owner
one owner, never two
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.
jsonparser has one owner, the parser component. The counts on the node are links, not a second dashboard.
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.
STK-REQ-005
stakeholder. What the library promises the people who depend on it.
Rests on
up. What the requirement rests on.
Blast radius
down. What a change can reach.
SYS-REQ-009
system. Set must update the addressed JSON value without corrupting unrelated structure.
Hazard
what must not happen. A slot in the model, not a record from that project.
Fig. 03 · One pair from jsonparser. The hazard box is a slot in the model, not a record from that project. Up is what the requirement rests on. Down is what a change can reach.
The same requirement, both ways. Up is what it rests on. Down is what a change can reach.
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 check, scenario, or demo bound to each obligation
04the run, against this revision of the code and the graph
05the verdict: verified, stale, violated, or not established
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 which text moved. The review says what you are accepting, and why you should believe it.
The same package is in the pull request and the portal. It is bound to this revision. A green check is readiness. Acceptance is a separate decision.
What the review answers
01 What am I accepting? The behavior that changes, and the approved intent it sits under.
02 What could it affect? What must stay true, and the widest reach of the change.
03 Why should I believe it works? What ran against this revision. A check, a scenario, an API exchange, a migration, or a narrated demo attached to the review.
04 What remains unresolved? What failed, what is stale, what is missing, and what still needs a person.
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.
·NOT ESTABLISHED
The evidence this claim needs is absent. Missing evidence stays visible. It is not a pass.
·NEEDS A DECISION
A person still has to accept it. The evidence does not decide. No acceptance is recorded until they do.
Nobody has to remember which document went out of date. The graph carries the dependency, so it can raise its own hand. A waiver is an explicit exception a person accepted. Superseded means a newer approved requirement replaced this one.
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.
Recovered intent starts as a candidate. An authorized person or policy establishes which promises govern the change. Agree approval authority before work starts. Delegate lower-assurance work to agents within a defined scope; reserve higher-assurance intent and consequential exceptions for a person. Changes to these boundaries follow the previously approved policy. A passing check supplies evidence. It does not grant permission to merge or deploy.
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 runs where you run it. Checks, demos and reproducers stay on your runners, with your secrets. The gate that blocks a bad merge is a step in your CI.
Your repository
the tree on disk
Requirements
plain files, under your licence
Bindings
obligations and evidence bindings, versioned with the code
Checks
checks, demos, and reproducers. They run on your runners.
The gate
in your CI configuration, with your secrets
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.
Start with one change or component, then expand along its dependencies. Retained requirements, tests and decisions give the next engagement a starting point. Measure whether that reuse reduces setup and review effort.
This run does not pass. A gating check is marked Fail, so the change is not ready to accept.
Two ways to work with Proof
Software factory
Delegate one change or a bounded backlog. Proof recovers the relevant intent, coordinates implementation with your coding agents, runs the required verification and retains the Change record. Your team sets the scope and authority. Scope a factory engagement →
Continuous audit
Keep implementation with your engineers and agents. Proof works alongside them to maintain requirements, investigate hazards and produce evidence for their changes. Fixes stay with your team unless you ask us to include them. Explore the audit →
A retry setting changes. The old check no longer supports the promise. Follow the actual passing, failing and corrected runs, with the gaps still visible.
