b1ec95450a69 = b1ec95450a69VERIFIEDRequired evidence is satisfied and the evaluated tree landed.Your checks passed.
Did that exact code land?
GitHub, CI and review evaluate one specific candidate. Merge Proof follows that evidence through landing and shows whether the evaluated content is actually the content that became merge truth.
Every required check passed for PR #41 against main at M0.
An ordinary PR moved main to M1. With loose required checks and no merge queue, PR #41 could merge without that new combination being retested.
Merge Proof compares the evaluated tree with the actual landed tree → MATCH, MISMATCH, OR NOT_PROVEN.
GitHub-native evidence for an exact observed state.
Verdict: VERIFIED / NOT_PROVEN / FAIL. Freshness: CURRENT / STALE.
The receipt records what GitHub reported at that point in time. It is not an atomic GitHub decision or a guarantee about a future merge.
Receipt Checks stay with the PR. Not an AI reviewer; neither NOT_PROVEN nor STALE means bad code.
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?
HOW MERGE PROOF KNOWS
Bind the evidence. Identify what landed. Compare.
GitHub reports checks, reviews and merge history. Git commit and tree IDs name the exact content. Merge Proof keeps those facts distinct and makes the deterministic comparison.
- Provider evidenceGitHub evidenceChecks, reviews and PR state bound to one observed candidate.
- Git identityEvaluated tree
b1ec95450a69 - Provider historyLanding observationMerged commit and landing event, when available.
- Git identityActual landed tree
13426dad6335or unavailable. - Merge ProofCompareSame, different, or missing a required fact.
b1ec95450a69 ≠ 13426dad6335FAIL · DIFFERENT CONTENT LANDEDA sufficiently bound comparison demonstrated a mismatch.b1ec95450a69 vs unavailableNOT_PROVENThe required landing comparison cannot be completed, so Merge Proof does not guess.Important boundary: Git identities identify content. They do not independently authenticate GitHub's checks, reviews or merge records.
THREE HONEST OUTCOMES
What became merge truth?
Same proof chain.
Different evidence conclusions.
EXAMPLE PROOF · VERIFIED
The evaluated tree is the tree that landed.
See candidate, evidence, currentness, landed tree, and the exact relationship.
Inspect VERIFIED →EXAMPLE PROOF · FAIL
Different content landed.
Evidence applied to candidate A. The observed landed tree was B.
Inspect FAIL →EXAMPLE PROOF · NOT_PROVEN
A required landing fact is missing.
Merge Proof shows what it established, what it could not, and refuses to guess.
Inspect NOT_PROVEN →SAFE TO TRY
Try it on a real PR.
7 days free. No card. Merge Proof observes and reports without blocking your merges. Early Access currently reports what happened rather than enabling a required merge policy during the trial.
CONNECT GITHUBSECURITY & ACCESS
Don't trust Merge Proof more than necessary.
See exactly what authority you grant before connecting.
Can Merge Proof access source?
Yes. Contents read is real source access. Workflow text, API patch text and exact Git objects may reach the server to bind identities and reconstruct supported tree facts.
Do you store my source?
Receipts store normalized evidence, paths, hashes and proof facts—not incidental patch or decoded workflow text. A private partial bare mirror retains exact Git objects and receipt refs for replay.
Does my source go to AI?
No. Source contents are not sent to an LLM or AI provider, and no AI model decides the verdict.
Can Merge Proof change my code?
Not through the standard connection. It has no Contents write authority and cannot push commits or modify repository files.
What can Merge Proof write?
Checks read/write lets it publish or update its receipt Check on the PR. That does not grant repository-file write authority.
FULL PERMISSION & DATA-HANDLING DETAILS
Don't trust Merge Proof more than necessary. See the exact authority before connecting.
Standard GitHub App repository access
- Read: Actions, Administration, Commit statuses, Contents, Merge queues, Pull requests, and GitHub's mandatory Metadata permission. These reads collect workflow/check evidence, repository rules, Git identities, merge-queue state, PR state, and landed content identifiers.
- Checks: read and write. Read check results and publish or update this App's Merge Proof Check output; it cannot change repository files.
- Organization members: read. Verify that the signed-in billing user is an organization owner.
GitHub sign-in: the OAuth request adds no extra OAuth scopes. Its short-lived user token is kept in process memory while Merge Proof checks identity, App installations, authorized repositories, and organization-owner status.
Technical access and processing: Contents read is real source access. GitHub responses can include workflow text and diff patches, and reconstruction fetches exact Git objects into a private partial bare mirror. Merge Proof uses these inputs to bind identifiers, inspect workflow action references and deterministically reconstruct trees; it does not execute customer code.
Persistence and AI boundary: receipts retain normalized evidence, identifiers, paths, hashes, rules, checks, reviews, actors, workflow provenance and reconstructed Git facts. Exact Git objects and receipt references are retained for replay. Incidental API patch text and decoded workflow text are not written into receipts. No source contents are sent to an LLM or AI provider; no AI model decides the verdict.
Write authority: the standard grant does not include Contents write, Secrets, Workflows write or organization administration. It cannot push commits, change branches or files, merge or close PRs, post PR comments, alter repository settings, edit branch protection/rulesets or modify Actions workflows. A separate optional Enhanced Policy Proof companion, if explicitly enabled later, has repository Administration write authority but is constrained by Merge Proof to policy reads; it is not part of this standard connection.
After uninstall or revocation: new collection stops and hosted access fails closed because current installation/repository access is rechecked. Historical receipts, evidence, retained Git objects, account records and operational backups are not automatically erased; current code defines durable retention, not a customer-selectable deletion deadline.
MORE THAN A GREEN LIGHT
Fast work. Clear evidence.
One deterministic receipt.
No AI model decides the verdict.
Was this version checked?
Connects check evidence to the observed version. Surfaces changes to the new work or the main code while it waits.
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. When a landing can be bound, connects the receipt to landed content and keeps a portable record of what was observed.
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, ambiguous records and unavailable provider reads remain evidence gaps. Base movement alone is not a bug or an automatic failed verdict.
The Standard GitHub App uses Administration Read. Optional Enhanced Policy Proof is a separately authorized, repository-bound Administration Write policy reader for policy reads only; it cannot change repository administration. If the optional reader is unavailable or GitHub cannot provide a needed detail, the affected policy claim remains NOT_PROVEN.
AI can inspect its own work, including GitHub. Merge Proof adds a 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: for a CURRENT receipt, available evidence sufficiently 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. Missing, ambiguous, unsupported or unavailable provider evidence stays NOT_PROVEN. 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: sufficiently bound evidence demonstrated that a required condition was unmet. Collection uncertainty, missing evidence and provider unavailability are NOT_PROVEN instead. Neither verdict is a judgment that your code is bad.
Receipt: a saved record of the evidence, verdict, gaps and next action at that moment. When landing can be bound, a portable receipt can carry that evidence with the landed content.
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. GitHub responses may include workflow text and patch text in transit; that incidental text is not stored in receipts, rendered, logged or sent to a model. Deterministic reconstruction fetches exact Git objects into a private partial bare mirror and retains them for replay; it does not execute customer code. Stored evidence includes sensitive repository metadata such as paths, identifiers, SHAs, normalized checks and rules, plus retained Git objects; 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.