Skip to main content
Use Release to choose which saved prompt version is in production. Each version must pass the prompt’s required evaluation policies before you can publish it. This guide continues with Support ticket triage from the Quickstart. It uses the completed Support triage v1 evaluation and the Support triage v2 candidate from Results and comparison. Use the synthetic example while learning the release flow.

Understand version states

Selecting a version in Build or Version readiness only changes what you are viewing. Click Publish version after the checks pass to change production. See Save changes or create a new draft for the editing workflow. Previously evaluated versions stay read-only after another version replaces them in production.

Before you publish

An organization owner or admin must create policies, save release settings, and publish versions. Other users with access can inspect readiness and results. You need at least one completed dataset evaluation with a required rule. A run with only advisory rules, or no evaluation rules, cannot establish a release policy. If you have not prepared this evidence, run the eight-ticket evaluation first.
The example’s Contains JSON rule only checks whether JSON can be found in the response. Both v1 and v2 passed all eight cases even though v1 assigned the wrong priority to the password-reset ticket. Use rules that check the behavior you need before relying on release checks for a real deployment. Review the recorded mismatch.

Set the required evaluations

Release settings apply to the whole prompt. You configure them once, then check each version against the saved selection.
1

Create a policy from saved evidence

Open Release, select Support ticket triage, then open Release settings and click New policy.In Source evaluation, select the completed Support triage v1 run. The policy uses the dataset snapshot and evaluation rules saved with that run. Its label comes from the source evaluation’s name.
2

Choose the thresholds

For this example, enter:This example uses a deterministic rule, so it needs no AI judge calibration. The checked option does not add an AI judge to the evaluation.
3

Save the prompt's requirements

Click Create policy. Confirm the new policy is selected, then click Save release settings.Creating a policy and saving the required selection are separate actions. Until you save, the selection shows Unsaved changes and the other release tabs are disabled.
New release policy for Support triage v1, with minimum coverage and pass rate both set to 100 percent, maximum regressions set to zero, and AI judge calibration required.

The policy uses the completed v1 evaluation's dataset and rules, with 100% coverage, 100% pass rate, and zero allowed regressions.

Each policy is a saved version of the requirements. To change thresholds or use a newer dataset or rule snapshot, click New policy, select an appropriate completed evaluation, and create another policy version. Select it and click Save release settings.You can require up to 20 policies, with one selected policy for each dataset-and-rule snapshot pair. Selecting another policy for the same pair replaces the previous selection. Every selected policy must pass before a version can be published.Policy versions, prompt versions, and release-settings revisions have separate numbering. A policy labeled Support triage v1 · v1 can check prompt v2 when its evaluation uses the same saved dataset and rules.If someone changes release settings in another session, click Reload selection and review the current requirements before saving again.

Publish the first version

1

Select the version and its evaluation

Open Version readiness. Set Version to release to v1 and confirm Current production says No version published yet.Under the required policy, set Evaluation for this version to Support triage v1. The selector lists completed runs for this version with the policy’s saved dataset and rules. A matching run may already be selected.
2

Inspect the checks

Confirm scoring coverage and case pass rate are both 100%, with 8 of 8 cases scored and passed.Regressions shows Not required because no production version exists yet. AI judge calibration shows No approval missing for the deterministic-only example; this does not mean an AI judge was calibrated.
3

Publish

When the summary says Ready to publish, click Publish version.Confirm Published to production and Current production: v1. The publish action checks the requirements again and records the evidence used for this release.

Release v2 against current production

Prepare v2 using the password-reset clarification, then evaluate it with the same dataset snapshot, rules, model, API key, sampling settings, and repetitions as v1. You can reuse the completed v2 run from the Results guide.
  1. In Version readiness, set Version to release to v2. Confirm Current production is v1.
  2. Set Evaluation for this version to Support triage v2.
  3. Set Production evaluation to compare to Support triage v1. Only compatible runs from the current production version are listed. See comparison requirements.
  4. Review the check table. This recorded example has 100% coverage, 100% pass rate, and 0 regressions. Open either View results link to inspect the underlying evidence.
  5. When every required evaluation passes and the summary says Ready to publish, click Publish version. Confirm Current production changes to v2.
Support ticket triage v2 ready to publish, with v1 in current production, both evaluation runs selected, all eight cases scored and passed, and zero regressions.

Before publishing v2, Release checks its saved evaluation against the required policy and the compatible v1 production evaluation. These are recorded example results, not guaranteed model outcomes.

Resolve a blocked release

The summary and What needs to change identify missing evidence or failed checks. Resolve each required policy before publishing.

Inspect production history

Open Production history to see which versions were published, when they were published, and which version each release replaced. The table includes cases passed, regressions, and the release-settings revision used at publish time. In Evaluation runs, open the row’s menu and choose View evaluation to inspect its recorded results. These records describe the evidence used for that release; later requirement changes do not rewrite the earlier decision.
Production history showing two recorded releases: Support ticket triage v2 replacing v1 and v1 as the first release, each with eight of eight cases passed and an evaluation-run menu.

The example history records v1's first release and v2 replacing v1. Both used release-settings revision v1, with eight cases passed and zero recorded regressions.

Return to an earlier version

To return production to an earlier version, open Version readiness and choose that version under Version to release. You can also open its version link in Production history. Select its evaluation for each current policy, and select compatible evaluations of the version currently in production. If the required snapshots have changed since the earlier release, prepare matching evaluations for both versions first. When the earlier version passes the current requirements and shows Ready to publish, an owner or admin can click Publish version. This creates another recorded release. Opening an old version or its historical evidence does not change production. For the recorded example, selecting v1 again after releasing v2 checks Support triage v1 against Support triage v2. The current JSON-only policy still passes; the known password-reset priority mismatch is why your real release rules must cover the behavior you intend to preserve. After publishing, use Production quality and analytics to score new requests and inspect their production evidence.