PatchProof

A deterministic patch-verification control plane that combines self-hosted execution, risk signals, redacted logs, retained artifacts, and reviewable verdicts for humans and coding agents.

Role
Product design, full-stack engineering, and verification architecture
Delivery
VPS control plane + self-hosted runners
Status
Live product
PatchProof early-access homepage showing a fictional patch report with verification evidence and a review warning.

01 / How it works

The system, drawn end to end.

SELF-HOSTED EXECUTION BOUNDARYPatchhuman or agentRunnerdeterministic runRisk signalsRedacted logsArtifactsVerdictlinked to evidencePATCHPROOF / VERIFICATION RUN
  1. 01

    Evidence over confidence

    The interface distinguishes what was executed, what was observed, and what remains uncertain.

  2. 02

    Readable under pressure

    Verdicts summarize the important result while logs and artifacts remain available for deeper review.

  3. 03

    Private execution boundary

    Self-hosted runners keep source and sensitive build context inside the operator’s environment.

02 / The problem

The operating problem behind the interface.

A patch can look plausible in a diff while still failing in the target environment. Humans and coding agents need a consistent way to run the right checks, understand risk, and retain evidence before a change is accepted.

03 / The approach

A product model designed around the decision.

PatchProof turns verification into a reviewable product surface. Each run combines deterministic execution, risk signals, redacted logs, retained artifacts, and a concise verdict that links conclusions back to evidence.

04 / Engineering scope

The system behind the product surface.

  1. 01Laravel and PHP control plane with a TypeScript and Node.js execution layer
  2. 02Risk-signal, log-redaction, artifact-retention, and verdict workflows
  3. 03Docker-based self-hosted runners separated from the hosted review surface