Was this version checked?
Connects check evidence to the observed version. Surfaces changes to the new work or the main code while it waits.
BUILD. REVIEW. PROVE.
PROVE
THE MERGE.
AI lets your code change fast.
Merge Proof checks whether the green checks you're trusting actually belong to the code you're about to merge.
Merge? Add the new work to the main version of your code.
Green checks? The automated checks passed. That doesn't mean bug-free.
Try free: 5 hosted proofs + 1 bounded historical scan.No card required.
TRY MERGE PROOF FREE
Connect GitHub → Pick a repo with an open PR → Get your receipt.
You'll need a GitHub account, a repository you can authorize, and an open PR for your first live proof.
New to this? What's a repo or PR?
Repository (repo): your project's code and history on GitHub. Pull request (PR): new work proposed for review, waiting to be added to the main code. You'll choose an existing open PR after connecting GitHub.
Prefer local? Free CLI + GitHub Action →
TESTS ASK
Did the code behave the way the tests expected?
MERGE PROOF ASKS
Does the evidence apply to the version you're about to merge?
MORE THAN A GREEN LIGHT
Fast work. Clear evidence.
One deterministic receipt.
No AI model decides the verdict.
What actually needs to be true?
Examines available project requirements and whether approvals apply to this version. Missing or unsupported evidence stays explicit.
Can I still rely on this receipt?
Compares refreshed evidence with the saved record. Keeps what was known then, and shows when it no longer describes now.
Under the hood: exact versions, execution evidence and limits
Hosted evidence binds the PR head, target base, applicable merge state and remote GitHub ref at observation. Check conclusions are distinguished from successful workflow/job/step execution records; status-only success does not prove execution. Even a workflow record does not prove checkout contents or test coverage.
Available branch protection and rulesets are evaluated together. Old-head approvals are insufficient under the implemented policy. Unsupported requirements and unavailable reads remain evidence gaps. Base movement alone is not a bug or an automatic failed verdict.
AI can inspect its own work, including GitHub. Merge Proof adds an independent deterministic evidence receipt. It does not guarantee correctness or security.
Inspect the hosted evidence policy on GitHub →EVIDENCE YOU CAN READ
A receipt.
Not a rubber stamp.
A record of what Merge Proof could actually establish about this merge at that moment.
Read the explanation. Inspect the HTML/JSON evidence. See the gap and the next action.
What do the labels mean? ↓MERGE PROOF / RECEIPTILLUSTRATIVE
- Verdict when issued
- NOT_PROVEN
- Freshness after a change
- STALE
- Evidence gap
- Required approval could not be established.
- What changed
- The proposed code changed after this receipt was issued.
- Next action
- Re-proof the current version. Inspect any remaining evidence gaps.
The original receipt stays unchanged. Freshness is reported separately. This is an explanation of the format, not a live result.
NEW TO THIS?
Same evidence. Human words.
PR, repository & merge
Repository: a project's code and history. PR / pull request: proposed new work waiting for review and addition to the main code. Merge: integrating that work into the target version of the project.
Green checks & CI
CI (Continuous Integration): automated workflows that build, test or check changes. Green checks: GitHub reporting that automated checks passed. Passing checks don't establish that code is bug-free.
Branch, main, base, head & SHA
Branch: a separate line of development. Main: the primary version the team builds around; its branch may have another name. Base: the version receiving the changes. Head: the proposed version. SHA: the Git identifier used to tell exact versions apart.
VERIFIED & NOT_PROVEN
VERIFIED: available evidence satisfies the implemented checks for the stated scope and exact observed state. It is not a correctness or security guarantee.
NOT_PROVEN: Merge Proof could not establish everything required from the available evidence. This does not mean broken, buggy or unsafe. The receipt explains the gap.
STALE & currentness unavailable
STALE: something relevant changed. The old proof should not be treated as proof of what is there now. It does not mean the code is broken.
Freshness is separate from the original verdict. Without a fresh observation, the receipt shows CURRENTNESS UNAVAILABLE / REFRESH REQUIRED. Time passing alone does not make evidence stale. Re-proof evaluates the current situation.
FAIL & receipt
FAIL: the analysis could not reliably complete. No hosted proof debit. This is not a judgment that your code is bad.
Receipt: a saved record of the evidence, verdict, gaps and next action at that moment.
START WITH THE EVIDENCE
Try it free. Keep building.
No card for the free start.
No automatic overage charge.
TRY HOSTED FREE
$0
5 hosted proofs + 1 bounded historical scan.
No card required. Connect GitHub, authorize a repository, and pick an open PR.
TRY MERGE PROOF FREEPRO
$29/month
per active developer
50 hosted proofs per active developer per month.
Automatic re-proof on PR changes, GitHub Checks, immutable receipt history, HTML/JSON evidence.
Additional proofs: $5 for 5, explicitly purchased. No automatic overage charge.
Prefer local? Free forever. MIT CLI + GitHub Action, with deterministic analysis and offline local operation. Use free local →
What counts as a proof or an active developer?
Count distinct human GitHub IDs opening covered PRs or pushing covered commits; exclude bots and inactive organization members. One human counts once across the paying account’s installations. Review your count before checkout. Quantity increases require customer confirmation; no proration. Decreases apply at renewal.
Included allowance is pooled at the paying-account level and resets at monthly renewal without rollover. Purchased top-ups remain until used, after included proofs. Same-head retrieval, refresh and retry do not debit again. A completed applicable new-head VERIFIED or NOT_PROVEN proof uses one unit.
What's in the bounded historical scan?
Look back at what available evidence can establish about previous merges. The free scan covers up to 5 merged PRs among the 30 most recently updated closed PRs. Unsupported history stays unavailable. Current rules cannot establish historical approval validity. The scan uses no live-proof allowance and does not count bugs prevented.
Trust, access & private receipts
No AI model decides your proof. Hosted processing accesses GitHub evidence; we do not claim it never sees code. Private receipts require current authorized repository access. Repository access is rechecked for each hosted request; uninstalling the App revokes hosted receipt access while preserving its history.