Proof-backed pull requests
A proof-backed pull request earns the merge it asks for.
A proof-backed PR carries everything a reviewer and an auditor need in one place: the diff, the tests, CI status, the policy decision, control mapping where relevant, and a signature that makes the whole packet re-verifiable.
Boetica leads evidence completeness and re-verification rate on the evidence benchmark.Evidence packetVerified · Jun 2026Evidence packet: Independently verifier-checked, dated Jun 2026.
Proof-backed pull request, defined
A proof-backed pull request is an autonomous change whose PR carries a complete, signed evidence packet: change summary, diff, tests, CI result, policy decision, reviewer state, rollback note, and SOC 2 / NIST control-family mapping where a control is touched. The signature lets anyone re-verify the packet after merge.
Green CI tells you the tests that exist passed. It does not tell you what changed, why it was allowed, whether the right tests exist, or how to back it out. For autonomous work, that gap is the whole risk. A proof-backed pull request closes it by attaching the evidence the decision actually depends on.
The point is not more dashboards. It is putting provenance where the merge decision already happens — the PR — so reviewers approve from evidence, and auditors can re-verify the same packet months later without trusting a screenshot.
Beyond green CI
CI is necessary, not sufficient. A proof-backed PR records the model-route decision, output evaluation, diff-size and blast-radius controls, and any no-test justification — the context a reviewer needs to trust autonomous work, not just confirm it compiled.
- What changed and why, in plain language.
- The policy decision that allowed the run.
- Blast-radius and rollback context attached to the diff.
The evidence packet travels with the change
Provenance is attached to the PR, not stored in a side system. The packet binds the finding or spec, the diff, the tests, CI, the reviewer state, and the control mapping into one inspectable record.
- Tamper-evident hash over the packet contents.
- Timestamp, reviewer, and CI state recorded together.
- Control-family mapping when a security or compliance control is touched.
Signed means re-verifiable
A claim you cannot re-check is a claim you have to take on faith. KMS/Sigstore signing makes a proof-backed PR re-verifiable from its signature long after the run, which is what turns it into audit evidence.
- KMS/Sigstore signature over the evidence packet.
- Re-verification from the hash trail at any later date.
- Shareable through a scoped, expiring evidence room.
The proof behind the claims
Every claim on this page resolves to one of these signed artifacts.
Proof-backed pull requests — frequently asked
Why is green CI not enough for an autonomous PR?
Green CI confirms existing tests passed. It does not record what changed, why the run was allowed, whether the right tests exist, or how to roll back. A proof-backed PR attaches that context so the merge decision rests on evidence.
What is in the evidence packet?
Change summary, diff, tests, CI result, policy decision, reviewer state, rollback note, and control-family mapping where relevant — bound under a tamper-evident hash and signed.
Can the proof be checked after merge?
Yes. The packet is KMS/Sigstore signed, so it is re-verifiable from its signature and hash trail at any later date, including during an audit.
Related topics
Each guide is linked to its own signed proof.
- Autonomous remediationAutonomous remediation closes findings with proof, not tickets.Autonomous remediation turns a credible finding into a bounded, tested, reviewable pull request with a signed evidence packet — so the finding is closed and provable, not just re-assigned.
- SOC 2 evidence roomsA SOC 2 evidence room replaces the questionnaire with live proof.An evidence room is a scoped, expiring, verifier-backed space where a buyer or auditor reviews the same signed proof Boetica uses internally — hash-backed SOC 2 artifacts, pentest, threat model, and benchmark scorecards — without the workspace itself being exposed.
- Agentic SDLC governanceAgentic SDLC governance enforces policy before the agent starts.Governing AI coding agents is not a code-review step bolted on at the end. It is a preflight: policy, branch protection, budget, model routing, and autonomy level are resolved before a run executes, and autonomy demotes automatically when quality drops.
Move from reading to proof
See it working, then run it on your own repo.
Open the product surface, verify the signed scorecards behind the claims, or see how the commercial model works.