Inspiration

AI coding agents can produce polished interfaces, large diffs, and confident feature descriptions remarkably quickly. But engineering leads, reviewers, and hackathon judges still face a difficult question: what evidence proves that each claimed feature was actually designed, implemented, tested, and demonstrated? Transcripts and diffs provide activity, but they do not create a product-level chain of custody. Claim to Commit was inspired by the need for a clear, local, and trustworthy way to connect human decisions and Codex work to concrete repository evidence.

What it does

Claim to Commit is a local repository evidence workbench. It turns declared product claims into inspectable chains: human decision → Codex session → commit → changed files → passing test → visual proof A repository opts in through a machine-readable evidence manifest. Claim to Commit resolves every referenced artifact, applies transparent deterministic rules, and grades each claim as proven, partial, or unsupported. Audit Mode exposes missing evidence and explains exactly what would make a claim defensible. The demo includes a deliberately impressive but unsupported claim, which turns red because its commit, implementation, test, and visual evidence cannot be resolved. It is disclosed as an excluded audit control rather than counted as shipped functionality.

How we built it

The core product was built in this Codex session with GPT-5.6 using runnable vertical slices and descriptive commits. Codex helped translate the product rules into a TypeScript evidence schema, safe read-only Git adapters, deterministic scoring engine, SQLite scan history, Express API, React workbench, automated tests, documentation, and submission assets. The stack intentionally uses familiar tools: Node.js, TypeScript, React, Vite, Express, SQLite, Vitest, and the Git CLI. Everything operates locally, requires no account or paid service, and runs with one command: npm run demo Human decisions included the target audience, explicit-evidence policy, local-only architecture, scoring weights, negative-control treatment, visual direction, and scope cuts.

Challenges we ran into

The hardest problem was linking evidence without pretending that an inferred relationship is proof. Semantic matching could look impressive while producing unverifiable results, so we chose an explicit evidence contract and transparent validation rules. We also had to design an honest score. The unsupported demonstration claim must remain visible without lowering the completion score for genuinely shipped functionality. We solved this by declaring it as an excluded negative control and showing that exclusion directly in the formula. Other challenges included safely handling arbitrary local repository paths, attributing files to real commits, keeping every checkpoint runnable, and making the project audit its own evolving commit history.

Accomplishments that we're proud of

Claim to Commit is a complete, self-auditing product rather than a static visualization. It can scan a real Git repository, resolve six kinds of evidence, preserve immutable scan results, explain missing proof, and present the result through a polished reviewer-focused interface. Its own repository now reports 100% evidence coverage across four shipped claims while continuing to expose the unsupported audit control. The project includes 43 passing tests, a successful typecheck and production build, seed evidence, exact judge test steps, a one-command local experience, a public repository, and a 2:55 narrated demonstration.

What we learned

Evidence provenance works best when it is designed into the development process instead of reconstructed afterward. We learned that an AI-assisted project needs more than a transcript saying what happened. Reviewers need stable references to decisions, sessions, commits, files, tests, and visual artifacts—and they need to see unresolved references just as clearly as successful ones. We also learned that negative controls make an evidence system more credible. A trustworthy tool should demonstrate that it can reject a persuasive unsupported claim, not merely make every result green.

What's next for Claim to Commit | Verifiable Evidence for AI-Built Software

Next, Claim to Commit could generate evidence manifests from pull-request workflows, ingest CI test results, verify signed attestations, and export a concise evidence report for reviewers. Additional adapters could connect agent-session metadata, issue trackers, deployment records, and release artifacts while preserving the core rule: inferred relationships may assist discovery, but only explicit, resolvable evidence can prove a claim. The longer-term vision is a portable evidence layer for AI-assisted software delivery—giving teams a defensible answer to not only “What did the agent change?” but “What can this build actually prove?”

Built With

Share this project:

Updates