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

Automatically, when a deployment starts waiting for approval, unless an Org admin turned this off. The setting is Generate release risk automatically in Organization > AI and it is on by default. With it on, the summary is ready by the time someone opens the approval dialog. It costs 2 AI credits. The setting sits under Release risk summaries, and it is greyed out and shown off while that switch (or AI for the organization) is off; your choice is kept and comes back when you turn the parent on.

With the setting off, nothing is written until someone who can approve opens the approval dialog for a deployment that has no summary. The dialog then writes one. Turn the setting off to save 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 a fresh one is written.

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

ReuseCopy Anchor Link

A summary is reused, at no cost, when the same code was already assessed with the same release checks. Two deployments share a summary when they have the same repository, the same head commit, the same baseline commit (the last successful release they are compared with), the same prompt version and the same language, and their release checks are identical: approvals, release policy result, attestations and failures in this release. If any of these differ, for example the policy fails for one environment and passes for another, a fresh summary is written for that deployment. A summary written while something could not be read (the commit history, the policy or the attestations) is never reused. A reused summary says where it came from ("Reused from ...: same code, same baseline. No credits used.") and links to that deployment.

Reuse never crosses organizations. Each organization's summaries, and the credits they use, stay its own.

Regenerate in the dialog skips reuse: it always writes a new summary and uses 2 AI credits.

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.

Risk on the Pipelines pageCopy Anchor Link

When a pending deployment has a finished summary, the run's Events column and its expanded row show a risk badge (low, medium or high). Select it to open the approval dialog, where the full summary is.

Advisory, and what a policy can readCopy Anchor Link

The summary never approves or rejects a deployment 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.

A release policy can use the rating through the Release risk rule, in one direction only: the rating can add a requirement (a Prodgator approver, or a failed policy) and never removes one or approves a release. Below the rule's threshold the rule adds nothing: an approval from someone other than the person who deployed answers it, as it would at or above the threshold.

While the rating is being written the rule waits (for up to 10 minutes once it starts, or 15 minutes after the deployment starts waiting when it has not started). When there is no rating and none on the way, the rule is pending or fails as chosen in the rule, never passes. A rating is missing when the plan has no Release risk summaries, AI is off, there are no AI credits, the rating failed, or it was written for a different deployment. Turn on Generate release risk automatically in Organization > AI so it is ready in time, or it may be missing until someone opens the approval dialog.

The highest rating a deployment received counts, so regenerating a summary cannot lower it. Choosing fail at or above the threshold is not a defence against a determined author. The rating is model output over text the author controls (commit messages, pull request titles, branch names), so it can be influenced. Use the rule to ask for more review of risky releases, next to rules that check facts.

A rating can be older than the latest policy results or approvals: it is not rewritten when they change, only when someone regenerates it or a new summary is requested after the release's facts changed. A newer successful release to the environment makes it stale, and the rule then treats it as missing.

Policies see only four facts: the level, when it was written, the deployment it was written for and whether it was reused. The text of the summary is never exposed to a policy. See input.releaseRisk.

Output languageCopy Anchor Link

Summaries are shared by the whole organization, so each one is written once, in the organization's Default language (Organization > General; English when none is set).

If your language differs, the first time you open a summary Prodgator translates it for you. It shows "Translating...", then the translation with a Show original / Show translation link. The translation is made by Amazon Translate, is cached, and uses no AI credits. If translation is not available, or the organization reached its daily limit of 500 translations, you see the original with a short note. Code, commands, file paths, identifiers and product names stay as written, and evidence lines are never translated.

RelatedCopy Anchor Link