Skip to main content
PatchProof PatchProof

How PatchProof works

One verification contract. One bounded run. One reviewable proof.

PatchProof connects the policy in a repository to deterministic execution and a durable merge decision—without moving untrusted execution into the cloud control plane.

Follow the Quickstart Review security

The verification flow

Five stages from intent to decision.

  1. 01

    Declare

    The repository defines what proof requires.

    A versioned .patchproof.yml can describe runner labels, commands, environment variable names, health and browser checks, timeouts, risk policy, and artifact patterns.

    PatchProof can also detect common Node, PHP, Python, Go, Ruby, Rust, frontend, test, and Docker project signals when generating a starter configuration.

    .patchproof.yml yaml 
    version: 1
runner:
  labels: [linux, node, npm]
checks:
  install:
    - name: Install
      run: npm ci
  quality:
    - name: Test
      run: npm test
  2. 02

    Inspect

    The patch is evaluated before intuition takes over.

    Changed-file status and deterministic rules identify sensitive paths, removed tests, dependency sources, relaxed policies, CI permissions, Docker privileges, secret-bearing files, and other review signals.

    Risk findings describe evidence. They do not include patch bodies, credential values, command bodies, or sensitive dependency targets.

    High risk

    Authorization boundary changed

    app/Http/Middleware/…

    Review required · deterministic path rule
  3. 03

    Execute

    Checks run inside an authorized boundary.

    For a local proof, the CLI works from your authorized checkout. For a cloud run, a compatible self-hosted runner claims the job, clones authorized source into a per-run directory, applies deadlines, and cleans up the workspace it created.

    The cloud plans and records the run. It never executes repository commands and never receives a Docker socket.

    Installpassed · 31 s
    Buildpassed · 47 s
    Testspassed · 56 s
    Health200 · 184 ms
  4. 04

    Assemble

    Raw run data becomes a bounded proof.

    PatchProof combines execution state, deterministic risk, changed-file evidence, failed or skipped steps, URL checks, configured artifact results, redaction counts, and lifecycle interruptions.

    Logs and user-facing metadata are redacted before presentation. Selected artifacts remain subject to path, size, and retention limits.

  5. 05

    Decide

    The verdict points back to its evidence.

    Safe, warning, risky, blocked, and unknown verdicts express the merge posture. The recommendation and top concerns explain what a human or coding agent should do next.

    Local runs exit nonzero for risky, blocked, and unknown outcomes, so an automated loop stops rather than continuing past unsafe evidence.

    Warning

    Review before merge

    Commands passed, but a high-risk authorization change needs human confirmation.

Choose the current workflow

Local verification or a manual shared run.

Available now

Local working-tree proof

Best for a developer or coding agent iterating before review. It includes staged, unstaged tracked, and untracked changes when comparing against HEAD.

Set up local verification
Available now

Manual cloud proof

Best when a workspace needs shared runner execution and a centralized proof. A person or authorized CLI explicitly queues the run.

Enter early access

Manual-first in 0.1

A push does not automatically create a PatchProof run yet.

GitHub App automation, Gitea webhook ingestion, hosted runners, executable Docker previews, AI-written summaries, billing, and browser-based configuration editing are deferred. Today, you initiate verification locally or explicitly queue it through the cloud workflow.

Development updates

Start with one patch

Follow the first proof all the way through.

Build the runner from an authorized source checkout, generate a repository policy, and produce a redacted local proof.

Open the Quickstart Explore the product