AI release risk summary

A release risk summary helps the person approving a deployment see what is being released and where to look first. It is shown inside the approve and reject dialog, and as a one-line risk badge on the deployment's card while it waits for approval.

When a summary is writtenCopy Anchor Link

Never automatically. The first time someone who can approve opens the approval dialog for a deployment waiting for approval, Prodgator writes the summary. It costs 2 AI credits.

The summary belongs to the deployment and is shared by everyone in the organization. Opening the dialog again, or a second person opening it, shows the same summary at no cost until the facts behind it change: a newer successful deployment to compare with, new commits, new failures in the change set, a new policy evaluation or new attestations. Then the next open writes a fresh one. Regenerate inside the dialog always writes a new one.

A deployment that is no longer waiting for approval gets no summary.

What is comparedCopy Anchor Link

A summary assesses what changed since the last successful release to the same environment: the same repository, the same deployment environment and the same provider (GitHub, GitLab, Bitbucket or Azure DevOps). It does not judge the release by how earlier releases went.

• A deployment counts as released when it finished successfully, including one that went out without an approval (bypassed) or by an admin override.
• Failed, cancelled, rejected and rolled back deployments are skipped, and so are deployments that have not finished. A successful deployment with no recorded commit is skipped too, since there is nothing to compare with.
• Without an earlier successful deployment, the summary says this is the first release to the environment and reads the newest 20 commits up to this one.

What is readCopy Anchor Link

• The change set: the commits between the last successful release and this deployment, read from the repository's provider: the first line of each commit message (up to 50), the number of changed files, and the titles and labels of the pull requests (merge requests on GitLab) those commits came from (up to 20). When the history cannot be read, the summary says the changes are unknown; that is not a failed check. Azure Repos does not return line changes for a commit, so for Azure DevOps the summary sees file names and change types only, and it does not comment on what changed inside a file.
• Failures in this release: failed runs on the commit being released, and failed attempts to deploy it to this environment, with their failure explanation headline when one exists. These count as risks. A failure whose retry passed is noted as a possible flaky test.
• Earlier failures in the change set: failed runs and failed releases on older commits since the last successful release. Fixes are expected after a failed release, so these never raise the risk level: a later commit that fixes one is listed as a mitigation ("Fixes the failure in Deploy").
• Failures from before the last successful release, and failures on other branches, are not read.
• Policy results: the newest release policy evaluation of the deployment, rule by rule, when policies are bound to it.
• Attestations recorded for the deployment's commit, when your workflows send run reports.

Commit messages, pull request titles, branch and environment names are passed to the model as data; instructions written inside them are ignored.

What you getCopy Anchor Link

• A risk level: low when the change is small and every check passes; high when checks fail, a failure in this release looks related to the change, or the change touches migrations, authentication, payments or infrastructure; medium otherwise.
• A one-line headline, a list of what changes, concerns and mitigations, each citing the commits, pull requests, runs, policy evaluations or attestations it is based on.
• A checks table that starts with Change scope since last successful release, Failures in this release, Attestations for this commit, Approvals and Release policy (when policies are bound), followed by single policy rules.
• Look at first: what the approver should read before deciding.

Advisory onlyCopy Anchor Link

The summary never approves or rejects a deployment, is never an input to a release policy or a gate, and never changes a gate's settings. The Approve and Reject buttons work the same with or without it. The dialog says so under every summary.

Output languageCopy Anchor Link

Summaries are shared by the whole organization, so they are written in the organization's AI output language (Admin Console > AI).

RelatedCopy Anchor Link