System Prompt Canary Deployment Prompt

This prompt is for SRE and AI Operations teams that need to safely roll out a new system prompt version to a subset of production traffic before a full deployment. It generates a complete canary evaluation plan, including traffic splitting rules, monitoring metrics, success criteria, and automatic rollback triggers. Use this prompt when a system prompt change carries behavioral risk that cannot be fully validated in staging alone. The ideal user is an engineering lead or reliability engineer who controls the deployment pipeline and has access to production traffic routing, observability dashboards, and incident response procedures. The prompt assumes you already have a tested candidate system prompt and a baseline version running in production.

Do not use this prompt for simple text changes with no behavioral impact—such as fixing a typo, adjusting whitespace, or reordering non-functional instructions—or for environments where traffic splitting is not supported. It is also inappropriate for pre-release testing in staging; use the Behavioral Change Test Prompt or Policy Regression Test Prompt for offline validation first. This prompt is specifically for the production rollout phase, where you need a structured, measurable, and automatically reversible deployment plan. If your system prompt change introduces new tool-use permissions, data access boundaries, or refusal policies, the risk is high enough that a canary is essential, and this prompt will produce the guardrails you need.

Before using this prompt, gather your candidate system prompt, your baseline production prompt, your observability metrics catalog, and your traffic routing configuration. The prompt will ask you to specify [TRAFFIC_SPLIT_PERCENTAGE], [CANARY_DURATION_HOURS], [SUCCESS_METRICS], and [ROLLBACK_TRIGGERS]. If you cannot provide concrete values for these placeholders, the generated plan will be too generic to execute. After generating the plan, review it with your incident response team and ensure the automatic rollback triggers are wired into your deployment pipeline before starting the canary. Never deploy a canary without first validating that the rollback mechanism works in a dry-run scenario.

This prompt template is designed to produce a structured canary deployment plan for rolling out a new system prompt version. It forces the model to consider traffic splitting, monitoring metrics, success criteria, and automatic rollback triggers before you expose the new policy to all users. Use this when you need a concrete, testable plan—not just a policy document—before flipping a feature flag in production.

textCopy
You are an SRE architect specializing in safe AI policy rollouts. Your task is to produce a detailed canary deployment plan for a new system prompt version.

## Inputs
- [CURRENT_SYSTEM_PROMPT]
- [NEW_SYSTEM_PROMPT]
- [DEPLOYMENT_CONTEXT]: Describe the production environment, traffic volume, user base, and risk tolerance.
- [AVAILABLE_MONITORING]: List the metrics, logs, and dashboards you can observe (e.g., refusal rate, latency p99, user sentiment score, task completion rate).
- [CANARY_CONSTRAINTS]: Any limits on canary duration, maximum traffic percentage, or required approval gates.

## Output Schema
Return a JSON object with the following structure:
{
  "plan_name": "string",
  "traffic_splitting_rules": {
    "initial_canary_percentage": "number (1-100)",
    "ramp_schedule": [{"hour": "number", "percentage": "number"}],
    "control_group_percentage": "number"
  },
  "monitoring_metrics": [
    {
      "metric_name": "string",
      "description": "string",
      "baseline_value": "string or number",
      "success_criterion": "string (e.g., 'must not increase by more than 5%')",
      "alert_threshold": "string"
    }
  ],
  "automatic_rollback_triggers": [
    {
      "trigger_name": "string",
      "condition": "string (e.g., 'p99 latency > 2x baseline for 5 minutes')",
      "action": "string (e.g., 'set canary to 0% and page on-call')"
    }
  ],
  "promotion_gates": [
    {
      "gate_name": "string",
      "criteria": "string (e.g., 'All success criteria met for 4 consecutive hours')",
      "requires_approval": "boolean"
    }
  ],
  "canary_duration_estimate": "string (e.g., '6 hours minimum')",
  "rollback_procedure_summary": "string"
}

## Constraints
- The plan must be safe for a production environment with [RISK_LEVEL] risk tolerance.
- Do not propose a canary percentage below 1% or above 50% without explicit justification tied to the deployment context.
- Every automatic rollback trigger must be observable with the available monitoring listed above.
- If the new system prompt introduces a breaking behavioral change, flag it explicitly in a `breaking_change_notes` field inside the JSON.

To adapt this template, replace the bracketed placeholders with your specific details. The [CURRENT_SYSTEM_PROMPT] and [NEW_SYSTEM_PROMPT] should be the exact text you intend to deploy. The [DEPLOYMENT_CONTEXT] is critical for calibrating the plan's aggressiveness—a low-risk internal tool can ramp faster than a customer-facing compliance assistant. After generating the plan, validate that every proposed metric is actually instrumented in your observability stack before starting the canary.

The System Prompt Canary Deployment Prompt is designed to sit inside a release orchestration layer, not as a standalone chat interaction. It should be invoked programmatically whenever a new system prompt version is staged for production rollout. The prompt expects structured inputs describing the proposed policy change, the target traffic split, the monitoring metrics that define success, and the rollback triggers that will halt the canary if it degrades. The output is a machine-readable canary plan that downstream systems can execute, not a human-only document. This means the integration must parse the plan into actual traffic routing rules, metric queries, and alert configurations.

To wire this into an application, build a release pipeline step that calls the model with the prompt template, validates the output schema, and then translates the plan into infrastructure actions. The pipeline should: (1) load the proposed system prompt diff and change rationale into [POLICY_CHANGE_DETAILS]; (2) inject the current production baseline metrics into [BASELINE_METRICS]; (3) specify the canary traffic percentage, duration, and evaluation windows in [CANARY_PARAMETERS]; (4) define the monitoring metrics and their acceptable degradation thresholds in [SUCCESS_CRITERIA]; and (5) list the automatic rollback conditions in [ROLLBACK_TRIGGERS]. After the model returns the canary plan, validate that the output contains a valid traffic_split_rule, a metrics_to_monitor array with explicit thresholds, a promotion_gate object with pass/fail conditions, and a rollback_procedure with step-by-step actions. If validation fails, retry with a more constrained output schema or escalate to a human release manager. Log every generated plan, the validation result, and the final go/no-go decision for audit purposes.

For high-risk policy changes—such as those affecting safety refusals, data access boundaries, or compliance constraints—add a human approval gate after plan generation but before traffic routing begins. The generated plan should be surfaced in a review dashboard showing the proposed split, the metrics that will be monitored, and the rollback triggers. Only after explicit approval should the pipeline apply the traffic rules. During the canary, stream the monitored metrics into an evaluation harness that compares canary performance against the baseline. If any metric breaches its degradation threshold, the harness must execute the rollback procedure automatically—do not wait for human intervention. After the canary duration completes without rollback, run the promotion gate checks before shifting to full traffic. Record the entire canary lifecycle, including the generated plan, metric timeseries, and final disposition, as evidence for the system instruction audit trail.