Skip to main content
Prompt work has two separate concerns: editing the next version and deciding what your application should run. Adaline keeps those concerns separate so teams can keep improving a draft without accidentally changing production behavior.

​
The prompt lifecycle

LayerWhat it meansWho uses it
Editor draftThe current editable prompt state: model config, messages, variables, tools, schema, and settings.Prompt authors and reviewers.
Editor snapshotA captured prompt state used for history, comparison, evaluation, or deployment.Reviewers, deployments, and audit workflows.
Deployment snapshotThe prompt snapshot assigned to a deployment environment.Your runtime application and release owners.
Deployment environmentA named target such as development, QA, staging, or production.Release managers and application code.
Your application should read from the deployment environment it expects. It should not depend on whatever draft a user is currently editing.

​
What deployment captures

A deployment snapshot captures the prompt state needed to reproduce the version:
  • Provider and model configuration.
  • Model settings.
  • Messages and variables.
  • Tools and project tool references.
  • Response schema.
  • MCP server configuration when enabled.
  • The deployment environment.
  • Snapshot metadata, including source context when created from an Improve cycle.
This is why deployment comparison can show meaningful changes between versions instead of only saying that a prompt was updated.

​
Use environments as release lanes

Create environments that match how your team ships software.
Environment patternUse it when
DevelopmentPrompt authors need a safe place to test application integration.
QAA test team or automated suite validates behavior before staging.
StagingThe application should run the candidate prompt in a production-like environment.
ProductionEnd users receive the prompt behavior.
Keep environment names consistent across projects. When each project names release lanes differently, deployment reviews and automation become harder to audit.

​
Deploy from the prompt

1

Open the prompt

Open the prompt you want to ship.
2

Open Deploy

Go to the prompt’s deployment page and review the current environment state.
3

Compare before changing

Compare the current editor draft with the selected deployed version or another deployment snapshot.
4

Choose the environment

Select the environment that should receive the new snapshot.
5

Create the deployment snapshot

Confirm the deployment so the environment points to the new prompt version.

​
Improve approval and deployment

Improve has two review outcomes that affect prompts differently:
ActionWhat happens
ApproveApplies the selected candidate to the prompt editor and deploys it to the project’s primary deployment environment when one is configured. The confirmation dialog names the candidate and target environment.
Edit & approveApplies the selected candidate and opens the prompt editor. It does not deploy automatically.
RejectLeaves the prompt unchanged and records the review in history.
Use Approve only when you are ready for the selected candidate to become the deployed behavior for the target environment. Use Edit & approve when you want to adjust the candidate, run more tests, or route through your normal deployment process.
Approval is production-affecting when the project has a deployment environment wired as the primary target. Read the confirmation dialog before approving.

​
Compare deployments

Use deployment comparison when a release has meaningful risk. Compare:
  • Current editor draft versus production.
  • Staging versus production.
  • Current candidate versus last known good deployment.
  • Improve candidate versus baseline prompt.
Review changes in:
  • Model and provider.
  • Message text.
  • Variables and variable placement.
  • Response schema.
  • Tools and MCP configuration.
  • Cost, token, and latency expectations.
  • Evaluator and dataset results that justify the release.

​
Roll back safely

Rollback restores a previous deployment snapshot to the environment. Rollback is useful when:
  • Monitor shows a quality, latency, cost, or token regression.
  • Traces show the deployed prompt is failing normal production cases.
  • Behaviors show a new high-volume issue after deployment.
  • A provider or model change behaves differently than expected.
After rollback, keep the failed deployment in history. Use it as evidence for a dataset row, evaluator, or Improve focus note.

​
Runtime handoff checklist

Before application code reads a deployment:
  • Confirm the application is using the correct workspace, project, prompt, and environment identifiers.
  • Cache deployment configuration according to your application needs.
  • Refresh cache after deployment events or webhooks.
  • Keep API keys in a secret manager.
  • Log trace metadata that identifies release, route, environment, and prompt context.
  • Watch Monitor and Traces after shipping.

​
Next steps

Deploy

Configure environments, webhooks, comparison, rollback, and runtime handoff.

Release prompts safely

Use a release checklist before changing an environment.

Review Improve candidates

Approve, edit, or reject generated prompt candidates.

Monitor

Watch production metrics after deployment.

Traces

Inspect the exact requests behind a deployment outcome.