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.
Code moves fast. Do the green checks still belong?
Merge Proof checks whether the available GitHub evidence supports the exact code you’re about to merge.
- Platform / DevEx
- Teams with AI PRs
- Merge queue / required checks
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 Merge Proof free for 7 days. No card required.Report-only during trial.
TRY MERGE PROOF FREE
Your 7 days start with your first successful hosted proof—not when you connect GitHub or install the App. No card.
Connect GitHub → Authorize repositories → Merge Proof finds open PRs and starts proving automatically.
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. Choose an account or repository if more than one is available. No open PR yet? We watch for the next one; your trial has not started. “Prove it now” is optional.
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. This does not start the trial. 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 upfront.
No automatic charge at trial expiry.
7-DAY HOSTED TRIAL
$0
No card required. Report-only during trial.
The clock starts with your first successful hosted proof, not when you connect GitHub or install the App. Automatic proofs and re-proofs are report-only during trial.
TRY MERGE PROOF FREEYour 7 days start with your first successful hosted proof—not when you connect GitHub or install the App. No card.
PRO
$29/month
per active developer
Keep hosted proofs, automatic re-proofs, GitHub Checks and inspectable HTML/JSON receipts for $29/month per active developer.
No card for the trial. Choose paid Pro to continue; there’s no automatic charge when the trial ends.
Paid Pro supports optional administrator-configured enforcing gates. Technical capacity and evidence limits apply.
No automatic charge at trial expiry. Without a subscription, new hosted proofs, re-proofs and scans pause. Existing receipts remain accessible while you retain authorization, subject to retention and capacity limits.
What starts the seven-day trial?
The first CURRENT, collection-complete VERIFIED or NOT_PROVEN hosted receipt starts seven calendar days, exactly once. NOT_PROVEN means evidence is missing; it does not mean your code is broken. Failed, unavailable or stale collection does not start the clock. Connecting GitHub, installing the App, authorizing repositories and historical scans do not start it either.
One trial is shared across installations owned by the same GitHub account. Reinstalling or refreshing the same head does not restart it.
Does the trial block merges?
The trial does not enable new enforcing policies. New enforcement requires paid Pro and a repository administrator; GitHub must separately require the correct Merge Proof Check. Merge Proof never edits branch protection or rulesets.
Previously configured enforcing policies remain enforced. At hosted expiry they report failure; report-only notices are neutral. If GitHub requires the check, subscribe or remove that required check. Provider or permission failures can prevent delivery; automatic unblocking is not guaranteed. A passing policy Check is not necessarily a VERIFIED receipt.
Prefer local? Free forever. MIT CLI + GitHub Action, with deterministic analysis and offline local operation. Use free local →
Who counts as an active developer?
Distinct human GitHub IDs observed opening covered PRs or pushing covered commits. Bots, configured service identities and inactive organization members are excluded. One human counts once across the paying account’s installations. Initial pricing uses the preceding 30 days of observed covered activity; subsequent counts use the subscription month. Review the count before checkout. Increases require confirmation; changes take effect at renewal without proration.
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. One bounded scan does not start the trial or count bugs prevented. Squash/rebase reconstruction and historical approval validity may be unsupported or unavailable. New scan collection pauses when hosted access expires.
Trust, access & private receipts
No AI model decides your proof. Contents read is a real GitHub permission. The hosted collector projects GitHub responses to metadata; compare responses may contain patch text in transit, which is discarded rather than stored, rendered, logged or sent to a model. It does not clone a repository tree or execute customer code. Stored evidence includes sensitive repository metadata such as paths, identifiers, SHAs and normalized checks and rules; this is not “no customer data.” 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.