Skip to main content
PatchProof PatchProof

The proof is the product

Know what ran, what changed, and what to do next.

PatchProof turns a patch into a durable decision record: a clear verdict, a short list of concerns, concrete evidence, and the provenance behind it.

Create your first proof Read the Quickstart

Example proof · PP-184

Harden workspace authorization

Review before merge
Execution
Completed
Static risk
High
Verdict
Warning

Merge recommendation

Review the authorization boundary and confirm the new test coverage before merging.

Evidence

7 signals
  • Build and tests4 deterministic commands passed 02:14
  • Health checkExpected HTTP status received 184 ms
  • Authorization code changedHigh-risk path requires review 1 finding

Provenance

Recorded
Commit
7f3c2a1
Runner
self-hosted · linux/node
Policy
.patchproof.yml
Evidence
Logs redacted · 2 artifacts

Five answers in every useful proof

Decision first. Detail when you need it.

01

Verdict

Safe, warning, risky, blocked, or unknown—the merge posture is explicit.

02

Recommendation

A plain-language next step explains whether to merge, review, fix, or retry.

03

Top concerns

The failures and risks that deserve attention rise above the raw output.

04

Evidence

Checks, changed files, URL results, redacted logs, and artifacts support the conclusion.

05

Provenance

Configuration, working directory, duration, and timestamps anchor a local proof; shared cloud proofs add commit, branch, and runner context.

Three signals, three meanings

A completed run can still reveal an unsafe patch.

Execution status tells you whether the work ran. Static risk describes what deterministic analysis found. The verdict combines available evidence with policy to recommend the next action.

PatchProof shows all three independently so a green command never erases a critical risk finding—and a runner failure never masquerades as a code verdict.

Execution
Completed

All planned steps reached a terminal state.

Static risk
High

An authorization boundary changed.

Verdict
Warning

Review the finding before merge.

Deterministic evidence

More than a test runner. Less guesswork than a dashboard.

The verification policy and the changed patch determine what PatchProof records.

Configured commands

Install, quality, and optional command checks run with explicit timeout and blocking behavior.

Changed-file risk

Deterministic rules inspect sensitive files, dependency sources, CI, test integrity, Docker, environment, and policy changes.

Health checks

Expected HTTP status and timing become structured evidence instead of an unrecorded curl command.

Browser checks

Explicit smoke checks can verify page response, title, final URL, and expected text from the runner workspace.

Redacted logs

Runner and server-side redaction limit the chance that credentials or sensitive metadata reach the report.

Selected artifacts

Configured paths can contribute bounded artifact metadata and retained contents to the cloud proof.

Two manual-first workflows

Verify locally or coordinate through the control plane.

Available now

Local proof

Run against an authorized working tree. PatchProof includes committed and working-tree changes, executes the declared policy, and writes a redacted JSON proof under .patchproof/reports.

Local verification shell 
node /path/to/patchproof/apps/runner/dist/cli/index.js run \
  --base origin/main \
  --head HEAD
Available now

Manual cloud run

Create a project, connect a compatible self-hosted runner, and explicitly queue a run. The control plane keeps the resulting proof available to the workspace.

Repository execution still happens on your runner. The cloud coordinates the job and stores the proof with redacted logs and selected, bounded artifacts.

Product boundary

Automation and hosted execution are not part of 0.1.

Today’s early-access product supports local verification and explicitly queued cloud runs. It does not automatically react to repository events.

Read development updates
Deferred

Repository integrations

GitHub App installation, checks updates, and Gitea webhook ingestion are future phases.

Deferred

Hosted runners and previews

PatchProof does not provide hosted execution or boot and proxy Docker Compose previews today.

Deferred

Generated summaries and billing

AI-written interpretations, paid plans, and browser-based configuration editing are not available yet.

Trust boundary

Coordination in the cloud. Execution on your runner.

PatchProof keeps untrusted repository work outside the control plane while preserving a shared, reviewable proof.

  1. 01

    PatchProof Cloud

    Plans runs, matches runner capabilities, stores structured evidence with redacted logs, and enforces workspace access.

    • No repository execution
    • No Docker socket
    • Scoped orchestration tokens
  2. 02

    Self-hosted runner

    Claims the job, checks out authorized source, executes bounded commands, and redacts output.

    • Per-run workspace
    • Bounded time and logs
    • Customer-controlled network
  3. 03

    Reviewable proof

    Separates execution, risk, and verdict so the merge decision points back to concrete evidence.

    • Deterministic findings
    • Redacted logs, bounded artifacts
    • Commit and policy provenance

Start with one patch

Start with a patch you already understand.

Use PatchProof 0.1 to establish the evidence loop locally, then connect a self-hosted runner when your team needs a shared proof.

Create your workspace See how it works