What "Verified" Means

01 / Scope

A claim is only as strong as its scope.

Every claim here names three things before it says anything else: the scope it holds inside, the requirements it was judged against, and the evidence you can run yourself. Take one of the three away and the word “verified” carries no information.

When paperwork can be generated faster than it can be read, the artifact stops being evidence. So here is the working definition. A claim is verified when you can re-run it: the requirement it traces to, the check that enforces it, and the reproducer that pins the break, all executable by you, on your tree, without us in the room.

Scope is the load-bearing word. A verified claim holds for one declared component, at one code and graph version, against requirements a person approved. It says nothing about the module beside it, the release after it, or a behavior nobody wrote down. Every status published here carries the version it belongs to for that reason, and section 09 says what becomes of a claim once that version moves.

That is also why every claim is published with the route to its evidence attached. A requirement you cannot open, a check you cannot run, and a reproducer you cannot execute are three ways of saying the same thing: take our word for it.

Scope note: this is the bar we hold ourselves to, not a certification scheme. Nobody accredits it and nobody is asked to adopt it. It is published so you can hold us to it.

Last reviewed

30 August 2026

Why it is dated

This page states a bar and a set of technical limits, and both can change. When a clause or a limit moves, the date moves with it.

See a claim and its evidence → Open a live graph ↗ seeded product demo; read the labels first

Terminology · A promise is what the code owes its callers. Once it is approved at the assurance level you set, that promise is a requirement in the graph, and every obligation, test and finding below it is attached to it.

How the evidence gets made

Six steps, from what the code owes to a gate that enforces it

Recover the promises. Read the code, write down what it owes its callers, one sentence each.
Get them approved. A promise counts once it is approved at the assurance level you set for it.
Write the worst case. For each promise: what happens if it fails, and how bad.
Derive the obligations. What must be true under the promise, and the test that shows it.
Measure the evidence. Which test ran, and which conditions in the code it exercised.
Hold every commit to it. The same checks run on every change. A broken promise blocks the merge.

What you keep

In your repository, whether or not we are still involved

the promises, written down
approved promises, the approver recorded on each
a worst case for every promise
obligations, each tied to a test
the evidence, per condition, per commit
the gate, in your CI

The same six steps, and the graph they build → The instruments that run them →

02 / The bar

The specification is checked before code is judged.

A clause without an enforcement mechanism is a preference. The six clauses in sections 02 to 07 are the bar. Each names the machine check that fails when the clause is broken, and the external practice the clause is drawn from.

Clause 01 / 06 The specification checked before code

clause Every requirement in scope is written in structured English with formal semantics, then proven realizable, consistent and non-vacuous before any code is judged against it. A spec that contradicts itself, or that a do-nothing system could satisfy, is a defect in its own right, and it is found first.

the check Realizability, consistency and vacuity are discharged at spec time by two independent proof engines: the Kind2 model checker and the Z3 solver. A requirement that fails them never enters the audit.

the anchorNASA's FRET program, which gave structured English requirements machine-checkable semantics. In FRET's published research, a realizability check caught an eVTOL spec defect that permitted backwards flight, in 14 seconds.

03 / The bar

No reproducer, no finding.

Clause 02 / 06A finding you can run

clause Every finding ships with a runnable reproducer, run before delivery, with its result recorded, or it does not ship. A finding you cannot re-run is an opinion with formatting.

the check The reproducer is executed before delivery and its result recorded. A reproducer pins the finding one of two ways: it fails until the fix lands, or it asserts the broken behavior while that behavior is live and flips when the fix lands. The record says which. No recorded run, no ledger entry.

the anchor Coordinated-disclosure practice in security research: proof of concept before report, so the recipient can verify before they triage.

04 / The bar

Every claim traces to code and evidence.

Clause 03 / 06 Every declared trace link resolves

clause Every requirement in scope carries links to the code that implements it and the test that verifies it. Every declared trace link resolves; orphan-code analysis checks the other direction.

the check The annotation resolver walks every link on every run; a link that fails to resolve fails the gate, and code answering to no requirement is flagged as orphan from the other direction.

the anchor Bidirectional traceability, required by DO-178C in avionics and ISO 26262 in automotive, for the same reason it is required here: unlinked evidence cannot be audited.

Fig. 01 · Under each approved promise, what must be true, and the test that shows it. Every one of those links is walked on every run.

05 / The bar

Critical decisions get condition-level coverage.

Clause 04 / 06MC/DC on the decision logic under audit

clause The decision logic under audit gets condition-level MC/DC (modified condition/decision coverage): every condition in every scoped decision is shown to independently affect the outcome, so a test suite cannot look thorough while exercising half the logic. Together with clause 3, this is coverage counted twice: once against the intent, once against the code.

the checkMC/DC instrumentation measures coverage on the scoped decisions. The number is measured, never estimated.

the anchorDO-178C Level A, the coverage bar avionics sets for software whose failure is catastrophic.

Fig. 02 · Each condition is shown to matter on its own, not just that the test passed.

06 / The bar

People decide what machines may not.

Machines and software agents run every check on every commit, at a volume no person could reach. A person validates every finding before it reaches you, so you never open a finding that nobody checked. People sign the promises whose assurance level requires a person’s judgment, they sign this bar, and they decide which misses from public work get published.

Clause 05 / 06 Who signs, and who validates

clause Machines check everything, every time; a person validates every finding before it reaches you; findings derive their authority from a runnable reproducer, not from a signature. People sign the methodology bar, and every promise whose assurance level requires a person’s judgment. The level is declared on each requirement, and you set it. Approval authority is configured, not assumed: Proof ships with every assurance level open to an agent, and a team closes the levels it wants a person on. Every approval records who or what approved, at which level. Publishing a miss from public Proof work is also a person’s decision, though the postmortem itself carries no signature.

the check The gate refuses to count a requirement without a recorded approval identity — a person’s name at the levels you reserve for one, the agent’s at the levels you leave open — and refuses to deliver a finding without its reproducer run and its result recorded. A person then validates the finding before it reaches you. There is no delivery path that skips any of the three.

the anchor The oldest norm in professional practice: an audit opinion carries the engagement partner's name, an engineering drawing carries the stamp of the engineer who answers for it.

Swipe sideways to see the whole figure.

Fig. 03 · Above the line, machines run every check on every commit. Below it, people validate the finding and sign the promises that require a person.

Agents

Do the crunching: every check, every commit, and the drafts underneath them.

A person

Validates every finding before it reaches you, signs this bar and the promises that require a person’s judgment, and decides that a miss gets published in public Proof work.

Your engineers

Approve at the levels you reserve for a person. Proof reserves none by default, so you name the ones you keep. Everywhere else an agent’s approval counts, and the record names the agent and the level.

That line is the assurance level, declared per component and per requirement. It starts fully open, it is written into the configuration, and where it sits is your decision. That is why the word “approved” still means something in the graph: every approval records who or what approved, and at which level.

An agent may

Actions an agent takes without asking

draft a requirement, which lands marked as a draft
approve at any level your policy leaves open — every level, until you narrow it — and the record names the agent and the level
write a reproducer, and run it
rerun the obligations a change put in doubt
propose a change with its evidence attached

An agent may not

Actions reserved for a named person

approve at a level you reserve. Narrow the policy and a requirement at a reserved level waits for a person who owns the code
approve under any identity but its own
close a known issue
declare a defect class closed
mark evidence current without a code and graph version behind it
move the line between what a machine decides and what a person decides — it is agent_autonomous_for, under project.approval in proof.yaml, and it moves in a commit you review

Drafting is machine-assisted, and nothing is trusted as drafted. Deterministic checkers reject invalid work before a person ever sees it: requirements that fail realizability, reproducers whose recorded result is never checked, links that do not resolve. What survives them still does not lean on a signature. Proof ships with every assurance level open to an agent, and an agent’s approval counts there, recorded as the agent’s, at that level, and never as a person’s. Reserving a level is opt-out: set agent_autonomous_for: all: false and list only the levels you delegate, and at a level you kept proof approve refuses an agent outright and names the setting that refused it, so the requirement stays a draft and counts as nothing.

What the agent receives, and what it may touch → Where the names go →

07 / The bar

The gate reruns without us.

Clause 06 / 06 Evidence you can rerun yourself

clause The audit gate re-runs on every change and runs without us. If the evidence could only be checked in our presence, it would be testimony, and this page promised you evidence.

the check The gate runs in your CI, on your infrastructure, with no network dependency on us and no license check. If we disappear, it keeps running.

the anchor The reproducibility norm in experimental science: a result only the original lab can produce is not yet a result.

Fig. 04 · Four commits. Three pass. The broken one stops.

The requirements, the obligations, the reproducers and the gate configuration are files in your repository. That is what makes the last clause enforceable: the evidence outlives the engagement that produced it, and anyone on your side can reproduce a claim without asking us for anything.

Where the bar applies · The six clauses were written for the engagement that installs Proof, which is where the bar is first applied. They bind the standing gate afterwards in exactly the same way. The instruments behind the checks are documented separately.

The engagement built on this bar → The instruments →

08 / Change evidence

Every change carries its evidence.

Every change is a change record, whatever kind it is. The record declares its kind before it says anything else, because a feature change and a defect fix are held to different evidence.

Kindfeaturerefactorbehavior changedefect fix

A change record carries why the behavior changed, the component that owns it, the requirements it introduced or disturbed, the diff, the documentation, the measured blast radius, the tests, the review, and the final verification state. A defect fix carries all of that and more: the originating known issue, the original reproducer, the root cause, the evidence that the individual instance is fixed, any evidence toward closing the wider class, sibling-defect analysis, and permanent regression evidence. Those extra fields exist because a fix makes a stronger claim than a feature does, and section 10 is about the part of that claim most fixes have not earned.

A change record is worth more than a green pipeline for a reason that has nothing to do with fixes: a pipeline reports the checks that ran, and the record also names the ones that should have run and did not.

The complete record model, field by field → Where the record sits in the graph →

09 / Status

Stale is not violated.

Software knowledge becomes dangerous when it silently goes stale. Stale evidence means a check must run again. It does not mean the requirement is broken. Proof holds a claim whose evidence stopped binding apart from a claim a check has contradicted, because the two ask you for different things.

Verified

The obligation ran and passed against a known code and graph version. The claim is current for that version and no other. what it asks of you · nothing

Evidence stale

The code, the requirement, or the document under the claim moved, so the evidence no longer binds to what is there now. Proof does not declare the requirement false. It withdraws yesterday's confidence until the affected obligations are reviewed or rerun. what it asks of you · a rerun, or a review

Violated

A check ran against the current version and failed. The claim is not withdrawn. It is contradicted, and there is a known issue with a reproducer that proves it. what it asks of you · a fix

Stale is a question. Violated is an answer.

How it is counted · A stale claim is never counted as verified and never counted as violated. It is counted as stale, and the change record carries the list of what must run, marked EVIDENCE REQUIRED, until somebody clears it.

Evidence going stale, on a record → Watch a claim go stale →

10 / Closure

One fixed instance is not a closed defect class.

A passing reproducer proves the known instance is gone. Closing the whole defect class takes broader evidence, and a record says which of the two it has earned.

After a fix, the reproducer stays. When a known issue is fixed, its reproducer stays in your suite and runs on every commit. That pins the instance: the release that would bring this one back turns the gate red. It is not closure of the class, and the record does not pretend it is.

Swipe sideways to see all ten releases.

Fig. 05 · One known issue, ten releases. Once its reproducer is in your suite, the release that would bring that instance back turns the gate red. The figure says nothing about the rest of the class; the two rungs below do.

KI-3 on buger/jsonparser is one. Set with an array-index path component under an object parent produced malformed JSON and returned it with a nil error. It is fixed, and its reproducer is retained in the suite. Read the record →

Rung 1

Reproducer passes

Established Individual instance fixed

Rung 2

Broader obligations pass
Sibling sweep
Hazard evidence
Blast-radius verification

Only then Defect class closed

Until all four inputs are in, the record says the instance is fixed and says nothing about the class. Proof does not print DEFECT CLASS CLOSED because a test went green, and no page here will say a class cannot come back because one reproducer is retained.

What one public record carries / on the class question DEFECT-260726-MFPA · buger/jsonparser

the originating issue

KI-3 · Set with an array-index path component under an object parent produces malformed JSON output

evidence the individual instance is fixed

TestSetAutoCoerce_KI3 · and the original reproducer, flipped to assert valid output

evidence toward closing the wider class

obligation class malformed_input attached to SYS-REQ-009, enforced on every run

sibling-defect analysis

the symmetric case, an object key under an array parent, checked and found already handled

permanent regression evidence

both tests retained in the suite

human or policy approval

reviewer human:buger · reviewed 26 July 2026

closure state on the record

covered_by_requirement · obligation attached to SYS-REQ-009 · the class is not declared closed

Read the last row against the two rungs · the record carries every field a complete defect record requires, and it still does not claim the class. Completeness is about what the record must say. Closure is about what the evidence has earned. A record can pass the first test and fail the second.

How it is counted · A known issue is not a defect record. Proof never mixes unresolved issues and verified defect records into one number, because the two say opposite things about the software.

Read against that record, the two rungs come apart. The instance is settled: the reproducer that produced malformed JSON now asserts valid output, and it runs on every commit. The class evidence is partial, and the record says so. The malformed_input obligation enforces the no-malformed-output invariant from here on, but a sweep of the rest of the mutation surface, and a blast-radius verification of the class, are absent. So the honest reading is: instance fixed, class evidence started, class not closed. That is the shape most fixes are in.

The two rungs on a record → Read the whole record ↗ More resolved records →

11 / Declared limits

The limits are part of the claim.

Assurance here is bounded on purpose: within a declared scope, for declared behaviors, with evidence commensurate with the consequence of failure. The table below is the edge of that boundary, by failure class, and it is published with the claims it bounds.

Failure class	Coverage	Note
Logic and intent gaps	Covered	The core of the audit: behavior that violates an approved requirement, or a requirement the team never wrote down.
Boundary and error-path defects	Covered	Condition-level coverage forces the branches ordinary suites skip. Error paths are where most of these hide.
Concurrency interleavings	Partial	Modeled where declared, rarely exhaustive. The report states which interleavings were checked.
Performance under load	Not covered	We make no load, soak or latency claims. A correct system can still be a slow one.
Security-relevant behavior	Covered, in scope	Security promises inside scope are audited like any other requirement (white-box; attack classes named at scoping). Not a certified pen test: see the engagement exclusions and the row below.
Penetration testing and red-teaming	Not provided	We do not deliver a certified penetration test, black-box red-teaming, infrastructure testing, or social engineering. Where a compliance framework or customer review requires one, engage a security firm; our evidence complements theirs and substitutes for none of it.
Third-party dependency internals	Not covered	Dependencies are held to their declared contracts. We do not audit inside them unless that is scoped separately.

One more limit, and it is the largest · an approved requirement can be wrong. If the sentence a person signed is wrong, the gate will defend the wrong promise on every commit until somebody notices. That is why the requirements are published alongside the evidence, and why a reproducer you can run yourself is worth more than a status we report.

The same limits, in the words of the engagement → What we got wrong, in public →

12 / Accountability

Hold us to it.

Names go on three things here: the promises whose assurance level requires a person’s judgment, this bar, and the misses we publish from public work. A person validates each finding before it reaches you, so you never open a finding that nobody checked, and the finding takes its authority from a reproducer you can run.

Deciding that a miss gets published in public Proof work is a person’s decision. Private engagement evidence stays private unless the customer authorizes disclosure. The postmortem itself carries no personal signature, so this page claims none. What it does carry is the layer that should have caught each escape and the blind spot that let it through, which is the part you can check against the code.

Our misses are published

On buger/jsonparser, two defects escaped the strict proof posture on that project. Set on an array index beyond the array's length overwrote the array instead of appending to it. A second empty-key panic site survived a hazard sweep that had reported all of them. The root-cause analysis is public and blameless: it names, for each escape, the layer that should have caught it and the blind spot that let it through.

Filed as a blameless postmortem, dated 26 July 2026, attributed in the document to proof-gap review. It carries no case number and no personal signature, so this page claims neither.

Read the root-cause analysis →

Start with one component. Pick the one you would least like to be asked about. The audit starts there, and the map and the gate are yours.

Request demo → Maintainer? Apply for an open-source audit →

Private early access: we take on a small number of engagements at a time. Private code stays private. We countersign your NDA before we read a line of your code.

Prefer a call? Ask for 20 minutes →

Leonid Bugaev
founder · this bar is published under his name, and the requirements are approved under it

What “verified” means here.