Deployment risk analysis

How a review chooses its domains

Fixed rules map the changed file paths to the domains a review considers. The model does not choose them. A workflow file brings in the deployment workflow domain, and a migration or schema file brings in datastore compatibility. A Dockerfile adds artifact identity and runtime architecture.

Each review records every domain as considered or skipped, with the rule and the files that matched. The reviews API returns each domain's status and the rule behind it, so you can check what a review covered.

An environment owner can switch off domains that do not apply.

The 18 risk domains

Evidence coverage runs on every review and cannot be switched off. It reports what the review could not check, so a gap never reads as a pass.

From risk to finding

Within the chosen domains, the reviewer writes concrete failure hypotheses. Proofline ranks them and investigates a bounded set against the exact commit and a snapshot of the environment.

Only hypotheses the evidence supports become findings. Each finding names its domain, severity, impact, and the evidence behind it. Follow a review from hypothesis to finding.

Questions

What is deployment risk analysis?

Deployment risk analysis reviews how a code change could fail once it deploys, given the infrastructure it lands in. It covers failures that tests in another environment cannot show, such as a permission, a limit, or a rollout setting.

Does a review with no findings mean a change is low risk?

No. A review with no findings means no finding emerged from the evidence available to that review. Its evidence coverage shows what the review could not read.

Can I see why a review skipped a risk domain?

Yes. Each review records every domain as considered or skipped, with the rule behind the decision. The reviews API returns each domain's status and that rule.