proofpath

Don’t trust an AI agent’s “done.” ProofPath turns its claims into testable requirements and refuses to mark them proven until you record what actually happened.

Comment

Inspiration

AI coding agents are getting very good at building software, but I kept running into a trust problem: they are also very good at saying “done.”

An agent might say that a feature works, that validation was tested, or even that something was “verified, not assumed.” But the agent's response is still a claim. It is not evidence that the requested behavior actually happened.

My background in security research and bug bounty helped shape how I thought about this problem. In security, saying “I think this vulnerability exists” is very different from providing a reproducible proof of concept. I wanted the same discipline when working with coding agents.

That led me to a simple question:

What if “done” had to be proven?

I built ProofPath around one principle:

The agent can make claims. The human provides observations. ProofPath decides what has actually been proven.

Instead of putting another AI model in charge of deciding whether the first AI is telling the truth, I wanted a transparent and deterministic verification layer between an AI coding agent's claims and the human who needs to trust the result.

What it does

ProofPath is a browser-based verifier for people working with AI coding agents.

The user starts by entering what they originally asked the coding agent to build. ProofPath converts that request into a Success Contract made of specific, testable requirements that the user reviews before verification begins.

Next, the user pastes the coding agent's response. ProofPath deliberately treats that response as claims, not evidence.

It also turns useful claims from the agent into things the human can actually check. If an agent claims:

125 @ 18% → $22.50

ProofPath can surface that claim as something that needs to be verified rather than silently trusting it.

The user then tests the application and records what actually happened.

For every requirement, ProofPath returns one of three outcomes:

  • PROVEN — the recorded observation provides sufficient evidence.
  • NOT PROVEN — there is not enough evidence yet.
  • CONTRADICTED — the observation conflicts with the requirement.

When proof is missing, ProofPath exposes a Proof Gap explaining what still needs to be observed or tested. The user can test again, add the missing observation, and re-run verification.

When something is fixed and tested again, newer evidence can supersede earlier evidence without erasing the history of what happened.

Once the required behavior has actually been demonstrated, ProofPath creates a Proof Card summarizing what was proven.

An AI coding agent saying:

“I tested it and everything works.”

does not make anything proven.

ProofPath separates what the agent claims from what the human actually observed.

How I built it

I built ProofPath V2 as a local-first web application using Next.js, React, TypeScript, Tailwind CSS, Zod, and Vitest.

One of my most important architectural decisions was intentionally not to put another LLM in charge of the final verification decision.

The verification engine is deterministic and rule-based: the same contract and evidence produce the same verification result.

The workflow is structured around:

Request → Success Contract → Agent Claims → Human Observations → Deterministic Verification → Proof Gaps → Re-test → Proof Card

I also designed the verifier defensively. It distinguishes observations from unsupported claims and handles cases such as hypothetical language, vague statements, error signals, conflicting evidence, prompt-injection-like text, and obfuscated input.

Everything runs in the browser. The current version does not require an account, backend AI service, or API key.

I used the Devpost Learn planning workflow to rebuild V2 around explicit project artifacts including scope.md, prd.md, and spec.md. That was a major change from my first approach: instead of immediately coding the idea, I first defined the scope, requirements, verification behavior, and acceptance criteria.

Challenges I ran into

The hardest problem was defining what “proof” actually means.

My first version taught me this the hard way. A sentence such as:

“The submission would be blocked.”

sounds like evidence, but it is only a hypothetical prediction. An early version of the verifier could be fooled by language like this.

Fixing that led to a much stricter distinction between claims, predictions, explanations, and observations.

Adversarial text created another challenge. Invisible Unicode characters and look-alike Cyrillic characters broke assumptions in the verification logic multiple times before I hardened the normalization and detection rules.

Even then, automated tests were not enough.

Mutation testing exposed an important verification rule that my existing tests were not actually protecting. Deliberately weakening the verifier and watching which tests failed became much more useful than simply seeing a green test suite.

One of the most useful lessons came from using ProofPath myself. Even as the person who built it, I did not always reach 100% proof on the first attempt. That forced me to improve the interface so ProofPath does not merely say NOT PROVEN — it explains the Proof Gap and tells the user what needs to be checked next.

Accomplishments that I'm proud of

I'm especially proud that ProofPath does not try to solve an AI trust problem by blindly adding another AI judge.

The final verification decision is deterministic and explainable.

One of my favorite tests involved a real coding-agent interaction. The agent confidently reported that its work was “verified, not assumed.” ProofPath still started at 0% proven, because the agent's confidence was not evidence.

I then performed the required checks myself, recorded what actually happened, and ProofPath moved the requirements toward 100% proven based on those observations.

That interaction captured exactly why I built the project.

I also built automated tests around normal cases, edge cases, adversarial language, conflicting evidence, Unicode obfuscation, and important verifier invariants. I then used mutation-style testing to deliberately disable important rules and check whether the test suite noticed.

Another accomplishment is preserving verification history. When a failed behavior is fixed, new evidence can supersede the old observation instead of pretending that the earlier failure never happened.

Most importantly, I turned an abstract idea —

“Don't blindly trust an AI agent when it says done.”

— into a visible workflow:

Claim → Test → Observation → Proof Gap → Re-test → Proven

What I learned

The biggest lesson was that verification is a different problem from generation.

AI systems can produce excellent code and convincing explanations, but confidence, detail, and even phrases like “verified” do not turn a statement into evidence.

ProofPath V1 made that lesson concrete. It could be fooled by language that sounded observational but was actually hypothetical. Later, Unicode and adversarial-input tests exposed assumptions I had not considered.

I also learned that a large passing test suite does not automatically mean the important rules are protected. Mutation testing forced me to ask a better question:

If I intentionally break this verification rule, will my tests catch it?

In at least one case, the answer was no. That was more valuable than another hundred green checks because it showed me exactly where my confidence was unjustified.

I also learned the value of testing the product as a real user rather than only testing its functions. A real end-to-end verification session exposed problems that unit-level reasoning had missed and directly changed the interface and Proof Gap guidance.

Finally, rebuilding V2 with explicit scope, product requirements, specifications, and acceptance criteria taught me that coding agents become much more useful when “done” is defined before implementation begins.

That lesson ultimately became part of ProofPath itself.

What's next for ProofPath

ProofPath V2 intentionally keeps the verification loop small and understandable.

There is also an important limitation I want to be explicit about: ProofPath does not currently run the target application or perform the tests itself. Human observations are self-reported, and the Proof Card reflects that rather than pretending to be an independent certification.

The next step is to strengthen evidence collection without destroying that transparency.

Future directions include automated browser-test evidence, richer evidence capture, coding-agent integrations, CI/CD verification, and stronger evidence provenance. A future version could, for example, capture browser actions and resulting states directly instead of requiring every observation to be manually entered.

I also see the underlying model extending beyond coding agents. The same distinction between claim and evidence could help with AI-generated documents, research workflows, designs, and other agentic systems.

The long-term vision is for ProofPath to become a lightweight proof-of-completion layer for AI agents.

Don't tell me it's done. Show me the proof.

Built With

Share this project:

Updates

Submission history