Check a change before it ships

What a check reads

Code. The repository and exact commit under review, or an exact base with an identified patch. A moving branch name is never code evidence.

Infrastructure. Recorded facts about the target environment from read-only cloud connections: services, databases, permissions, limits and the connections between them, each with its source and observation time.

Each environment has its own assessment. Evidence about staging does not establish a fact about production.

What a finding contains

A supported finding names the trigger, explains how the change and the environment combine into a failure, and cites the commit lines and recorded infrastructure facts it rests on. It suggests a fix.

Findings publish as review comments on the pull request, where your team already works. Read example findings on the homepage; the code-review guide covers the review capabilities in detail.

What a check does not claim

An absence of findings does not establish that a deployment will succeed, and Proofline never marks a change as safe. Required evidence that is missing, stale or unreachable keeps the assessment incomplete; supported findings still publish, and the gap appears as a setup task in the console.

Reviews are advisory by default. An administrator can configure a merge gate or deployment protection under an explicit policy. Proofline never merges changes or mutates your infrastructure.

After you push a fix

Proofline checks the new commit and keeps the earlier review and its evidence unchanged. Reviews are append-only, so a rerun creates a new record rather than rewriting the last one.