Staging-to-Production Acceptance Criteria Prompt

This prompt is designed for release managers, AI platform engineers, and QA leads who are responsible for the formal gatekeeping of a prompt's transition from staging to production. The core job-to-be-done is to transform a specific prompt version's observed behavior and performance data into a structured, machine-readable acceptance criteria document. This document serves as the single source of truth for a CI/CD pipeline, a release gate service, or a human approval workflow to make a deterministic promote or rollback decision. Use this prompt when you have a frozen prompt version in a staging environment and you need to define the exact quantitative thresholds, qualitative rubrics, required evidence types, and the classification of each condition as a blocking issue or a non-blocking warning.

The ideal user brings a clear understanding of the prompt's intended function, its critical failure modes, and the operational metrics that matter for production. Required context includes the raw prompt text, a summary of its purpose, the target risk level, and the specific evaluation dimensions to gate on, such as hallucination rate, latency, or schema compliance. The prompt is not a substitute for running evaluations; it consumes the results of your existing test suites. It is also not designed for generating test cases, performing the evaluations directly, or defining rollback triggers, which are handled by separate, dedicated playbooks in this content group. The output is a specification, not an execution log.

Do not use this prompt for exploratory prompt design or for evaluating a prompt that is still under active development. It is a release artifact generator, intended for the final stage of the promotion pipeline. Before using this prompt, ensure you have completed regression testing, canary analysis, and any qualitative human reviews. The acceptance criteria it produces should be versioned and stored alongside the prompt itself, creating a clear audit trail for every production deployment. If your workflow requires a weighted scorecard or a specific rollback trigger definition, use the sibling playbooks designed for those exact purposes before or in parallel with this one.

This prompt template produces a structured acceptance criteria document that defines the exact conditions a prompt must satisfy before promotion from staging to production. It generates pass/fail thresholds, required evidence types, and blocking versus warning conditions. The output is designed to be consumed by automated gate evaluation systems, CI/CD pipelines, and release approval workflows. Replace each square-bracket placeholder with your specific prompt version details, evaluation dimensions, and gating requirements before use.

textCopy
You are a release gate architect for AI prompt deployments. Your task is to produce a machine-readable acceptance criteria document for promoting a prompt from staging to production.

## INPUTS
- Prompt Version: [PROMPT_VERSION_ID]
- Prompt Description: [PROMPT_DESCRIPTION]
- Previous Production Version: [PREVIOUS_VERSION_ID or "none"]
- Evaluation Dimensions: [EVAL_DIMENSIONS_LIST]
- Risk Level: [RISK_LEVEL: low | medium | high | critical]
- Deployment Context: [DEPLOYMENT_CONTEXT]
- Required Approvers: [APPROVER_ROLES_LIST]

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "acceptance_criteria": {
    "document_metadata": {
      "prompt_version": string,
      "generated_at": string (ISO 8601),
      "risk_level": string,
      "required_approvers": [string]
    },
    "gates": [
      {
        "gate_id": string,
        "gate_name": string,
        "category": string (one of: "quantitative_metric", "qualitative_rubric", "operational_threshold", "compliance_check", "regression_check"),
        "description": string,
        "blocking": boolean,
        "threshold": {
          "metric": string,
          "operator": string (one of: "gte", "lte", "eq", "gt", "lt", "range"),
          "value": number or [number, number],
          "unit": string
        },
        "evidence_required": [
          {
            "evidence_type": string (one of: "eval_run_result", "human_review_signoff", "automated_test_output", "production_canary_metrics", "comparison_report", "audit_log"),
            "source": string,
            "format": string
          }
        ],
        "failure_action": string (one of: "block_release", "require_approval", "log_warning", "auto_rollback"),
        "rollback_trigger": boolean,
        "evaluation_window": {
          "duration": string,
          "minimum_samples": number
        }
      }
    ],
    "promotion_decision_rules": {
      "blocking_gates_must_pass": [string],
      "warning_gates_max_allowed": number,
      "approval_override_conditions": [string],
      "auto_promote_conditions": [string]
    },
    "rollback_triggers": [
      {
        "trigger_id": string,
        "condition": string,
        "metric": string,
        "threshold": number,
        "duration": string,
        "action": string
      }
    ],
    "evidence_checklist": [
      {
        "item_id": string,
        "description": string,
        "required_for": [string],
        "provided_by": string
      }
    ]
  }
}

## CONSTRAINTS
- Every gate must have at least one evidence requirement.
- Blocking gates must have clear, measurable thresholds.
- Rollback triggers must reference specific metrics and durations.
- For high or critical risk levels, require human review signoff for at least one blocking gate.
- Include gates for: format compliance, error rate, latency, semantic drift, and safety policy compliance.
- If a previous production version exists, include regression comparison gates.
- Warning conditions must not silently degrade into blocking conditions.
- All metric names must be resolvable in the evaluation harness.

## EXAMPLES
[EXAMPLES]

## TOOLS
[TOOLS]

Generate the acceptance criteria document now.

After pasting this template, adapt it by filling in the evaluation dimensions specific to your prompt's domain. For a RAG prompt, include citation accuracy and hallucination rate gates. For a customer-facing chat prompt, add tone consistency and refusal-rate gates. For high-risk deployments, ensure at least one blocking gate requires human review signoff. The output JSON can be fed directly into a gate evaluation harness that checks each threshold against actual metric values collected during staging validation, canary deployment, or A/B comparison runs. Validate the generated criteria document by checking that every gate has a measurable threshold, every blocking gate has a clear failure action, and rollback triggers reference metrics your observability stack can actually emit.

This prompt is designed to be a gate within a gate—it produces the machine-readable acceptance criteria document that downstream evaluation harnesses consume. The output is not a human-readable summary; it is a structured specification of pass/fail thresholds, required evidence types, and blocking vs. warning conditions. The implementation harness must therefore treat this prompt as a criteria generation step that feeds into automated evaluators, CI/CD checks, and release dashboards.

Validation and Schema Enforcement: The prompt's output must conform to a strict JSON schema before any downstream system trusts it. Implement a post-generation validation layer that checks: (1) every criterion has a unique id, a metric_name, a threshold with a numeric value and operator (e.g., gte, lte, eq), and a severity field set to either blocking or warning; (2) every evidence_type field references a known evidence source (e.g., eval_run, human_review, production_metric, schema_check); (3) no two criteria share the same id; and (4) all depends_on fields reference valid criterion IDs within the same document. If validation fails, retry the prompt once with the validation errors injected into the [CONSTRAINTS] placeholder. If it fails twice, escalate to a human reviewer and halt the release pipeline.

Integration Points: Wire this prompt into your release pipeline as a pre-gate artifact generator. When a prompt version is tagged for staging-to-production promotion, trigger this prompt with the [INPUT] containing the prompt's purpose, risk profile, and target metrics. The generated acceptance criteria document should be committed to your prompt registry alongside the prompt version. Downstream CI/CD steps then read this document to configure eval runners, set threshold checks, and populate release scorecards. For high-risk domains (healthcare, finance, safety-critical systems), add a mandatory human approval step where a release manager reviews the generated criteria for completeness and appropriateness before the document is used to gate the actual prompt. Log every generation, validation failure, and human override for audit trails.

Model Choice and Retry Strategy: Use a model with strong structured-output capabilities and a context window large enough to hold the full [INPUT], [CONSTRAINTS], and any prior validation errors. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable defaults. Set temperature=0 to maximize determinism. Implement a retry loop with exponential backoff (1s, 2s, 4s) for transient API failures. For validation failures, append the specific schema violations to the [CONSTRAINTS] field on retry rather than silently re-invoking the same prompt. Do not retry more than twice for the same input—persistent failures indicate a prompt design problem or an ambiguous input that needs human clarification.

What to Avoid: Do not treat this prompt's output as advisory. If the generated criteria are vague, unmeasurable, or missing blocking conditions, the entire release gate becomes unreliable. Avoid feeding the output directly into automated rollback systems without first validating that every threshold is numeric, every evidence source is reachable, and every blocking condition has a corresponding measurement pipeline. Never skip the human review step when the [RISK_LEVEL] is high or critical. Finally, version your acceptance criteria documents alongside your prompts—a criteria change is itself a release event that should be reviewed and approved.