Skip to main content
Prompt releases change customer-facing behavior. Treat them like software releases: review the diff, prove the change against examples, know the rollback target, and watch production after the environment changes. Use this page before shipping a prompt version to staging, QA, production, or any environment your application reads at runtime.

​
Release paths

Adaline supports several release paths:
PathUse it when
Deploy editor changesThe current prompt editor has changes you want to ship to an environment.
Promote a deploymentA snapshot that is current in one environment should move to another environment.
Approve from ImproveAn Improve candidate has passed review and should become the prompt version.
Edit & approve from ImproveAn Improve candidate is useful but needs manual edits or another release process.
RollbackA previous deployment snapshot should replace the current environment version.
Each path should leave an understandable record: what changed, why it changed, what evidence supported it, and which environment now runs it.

​
Pre-release checklist

Before deployment, confirm:
  • The prompt has the intended provider, model, messages, variables, tools, and response shape.
  • The target environment is the one your application will read.
  • The deployment diff is reviewed in Pretty, JSON, or YAML view as needed.
  • Golden datasets pass.
  • Regression datasets pass or failures are explicitly accepted.
  • Evaluator reasons make sense, not only evaluator scores.
  • Cost, token, and latency expectations are acceptable.
  • Tool and retrieval behavior has been checked if the prompt uses external context.
  • A rollback target exists and is easy to find.
  • Webhooks or cache refresh logic are configured if the runtime caches deployments.
Do not deploy only because a candidate improved one Behavior. A safe release also preserves existing quality, format, cost, latency, and tool-use expectations.

​
Review the Deploy page

The Deploy page gives you three review surfaces:
SurfaceWhat to check
Left railUndeployed changes, deployment history, environment filter, and Current badges.
Main panelPrompt content in Pretty view, raw JSON/YAML, and Diff Mode.
Right panelEnvironment selection, deploy action, deployment webhooks, integration IDs, and webhook executions.
Use the left rail to understand which snapshot you are looking at. Use the main panel to understand content. Use the right panel to understand environment impact.

​
Review diffs

Use Compare your deployments before a risky release. Review:
  • Model and provider changes.
  • Message changes, especially system instructions.
  • Variables and runtime context assumptions.
  • Tool definitions and project tool references.
  • Response format or structured-output expectations.
  • Any change introduced by an Improve candidate.
Diff Mode is most useful in JSON or YAML view. Pretty view is better for human reading; raw views are better for exact comparison.

​
Deploy editor changes

Use this when the editor has the version you want to ship.
1

Open Deploy

Open the prompt and go to Deploy.
2

Select Undeployed changes

The left rail shows Undeployed changes when the editor differs from an environment or an environment has no deployment yet.
3

Choose the environment

In the right panel, select the environment that should receive the editor snapshot.
4

Review content and diff

Use Pretty view for content review. Use JSON/YAML and Diff Mode when you need exact comparison.
5

Check webhooks

Confirm the deployment webhooks shown for the selected environment are expected.
6

Deploy

Click Deploy and confirm the environment in the dialog.
After deployment, the new snapshot appears in deployment history and can become the Current deployment for that environment.

​
Promote or roll back a snapshot

Open a deployed snapshot when you want to reuse it:
  • If the snapshot is current in its environment, use Deploy to… to deploy the same snapshot to another environment.
  • If the snapshot is older, use Rollback… to create a new deployment from that older version into the selected environment.
  • Use Open in Playground when you want to test that snapshot before acting.
Rollback is a recovery move, not a cleanup move. After rollback, keep the failed deployment as evidence for traces, datasets, evaluators, and Improve.

​
Improve approval and release

Improve can end in three review outcomes:
OutcomeRelease effect
ApproveApplies the candidate and deploys to the project’s primary deployment environment when one is configured.
Edit & approveApplies the candidate to the prompt editor and leaves deployment to the normal release flow.
RejectLeaves the prompt unchanged and keeps the cycle in history.
Use Approve only when the candidate is ready for the named environment. Use Edit & approve when you want another human edit, another evaluation run, or a staged deployment.

​
Post-release watch

After deployment:
  1. Watch Monitor for traffic, latency, cost, token usage, and evaluation score.
  2. Open representative Traces from the new release window.
  3. Check Behaviors after enough traffic has accumulated.
  4. Save failing or surprising spans to Datasets.
  5. Compare against the rollback target if metrics move unexpectedly.

​
Release packet

For production or high-risk releases, record:
  • Prompt and environment.
  • Deployment snapshot or current deployment.
  • Diff summary.
  • Evaluator and dataset results.
  • Behaviors or traces that motivated the change.
  • Webhook/cache refresh expectation.
  • Rollback target.
  • Post-release monitoring window.
The best prompt release is easy to explain later. A teammate should be able to answer what changed, why, how it was tested, where it deployed, and how to undo it.