System Instruction Release Gate Prompt

This prompt is for release managers and AI operations engineers who must approve a system prompt deployment. It produces a structured go/no-go assessment by evaluating test results, regression checks, canary performance, and rollback readiness. Use this prompt when a system instruction change is staged for production and you need a consistent, evidence-based gate decision before traffic is shifted. The prompt assumes you already have test artifacts, canary data, and a rollback plan to evaluate—it does not generate those artifacts.

The ideal user has access to concrete evidence: regression test pass/fail counts, canary performance metrics compared against baseline, a documented rollback procedure with estimated time-to-recovery, and a summary of the behavioral changes in the new system prompt version. Without these inputs, the prompt cannot produce a reliable assessment. The output is a structured decision record with a clear recommendation, confidence level, unresolved risks, and required sign-offs. This makes the prompt suitable for embedding in a CI/CD pipeline gate or a release management dashboard where human reviewers need a consistent evaluation format before approving a deployment.

Do not use this prompt for authoring system instructions, debugging individual model outputs, or designing test suites. It is not a replacement for automated regression testing or canary analysis—it consumes their outputs. Avoid using it when the evidence is incomplete or when the decision requires subjective judgment about product quality that cannot be grounded in test metrics. If the deployment context involves regulated domains, the output should be treated as an advisory assessment, not a substitute for compliance review. The prompt works best when paired with a human approval step that reviews the structured assessment and signs off on the final go/no-go decision.

This prompt template is designed for release managers and AI operations engineers who need to make consistent, evidence-based decisions about whether a system prompt change is safe to deploy. It forces a structured assessment against predefined gate criteria, requiring specific, traceable evidence for each check rather than subjective judgment. The template is intentionally conservative: missing or ambiguous data defaults to a blocker, preventing unsafe deployments that rely on assumptions.

textCopy
You are a release gate evaluator for AI system prompt deployments. Your task is to produce a structured go/no-go assessment based on the provided evidence. You must be conservative: if evidence is missing, incomplete, or ambiguous, flag it as a blocker. Do not assume passing results where data is absent.

## SYSTEM INSTRUCTION CHANGE CONTEXT
[SYSTEM_PROMPT_CHANGE_DESCRIPTION]

## TEST RESULTS
[TEST_SUITE_RESULTS]

## REGRESSION CHECK RESULTS
[REGRESSION_CHECK_RESULTS]

## CANARY PERFORMANCE DATA
[CANARY_PERFORMANCE_DATA]

## ROLLBACK PLAN
[ROLLBACK_PLAN]

## GATE CRITERIA
[GATE_CRITERIA_CHECKLIST]

## OUTPUT INSTRUCTIONS
Produce a JSON object with the following structure:
{
  "decision": "GO" | "NO_GO" | "NEEDS_REVIEW",
  "confidence": "HIGH" | "MEDIUM" | "LOW",
  "summary": "One-paragraph summary of the assessment",
  "gate_checks": [
    {
      "criterion": "Name of the gate criterion",
      "status": "PASS" | "FAIL" | "INCONCLUSIVE",
      "evidence": "Specific evidence supporting the status",
      "blocker": true | false
    }
  ],
  "blockers": ["List of blocking issues that prevent a GO decision"],
  "warnings": ["List of non-blocking concerns that should be monitored"],
  "rollback_readiness": "READY" | "PARTIAL" | "NOT_READY",
  "signoff_required": ["List of roles or individuals who must sign off before deployment"],
  "recommended_actions": ["List of actions to take before the next gate review"]
}

## CONSTRAINTS
- If any gate criterion marked as required in the checklist has a FAIL or INCONCLUSIVE status, the decision must be NO_GO or NEEDS_REVIEW.
- If rollback readiness is NOT_READY, the decision must be NO_GO.
- If canary data shows statistically significant degradation on safety or quality metrics, the decision must be NO_GO.
- Do not fabricate evidence. If data is missing, mark the criterion as INCONCLUSIVE and flag it as a blocker.
- Include specific, traceable evidence references for each gate check.

To adapt this template for your release pipeline, replace each square-bracket placeholder with structured data from your testing and observability systems. The [GATE_CRITERIA_CHECKLIST] should be a predefined list of required checks specific to your organization's risk tolerance—examples include behavioral regression pass rate, canary safety metric thresholds, rollback procedure validation, and stakeholder sign-off completion. The [TEST_SUITE_RESULTS] and [REGRESSION_CHECK_RESULTS] should include pass/fail counts, specific failure cases, and links to test run artifacts. The [CANARY_PERFORMANCE_DATA] must include statistical comparisons with confidence intervals, not just raw metric differences.

Before integrating this prompt into an automated release pipeline, validate that your evidence sources are machine-readable and consistently available. A common failure mode is feeding this prompt incomplete data and receiving a confident but incorrect GO decision because the model filled gaps with assumptions. Always pair this prompt with a validation step that checks whether all required evidence fields are populated before the evaluation runs. For high-risk deployments, require a human to review any NEEDS_REVIEW decision and sign off on the recommended actions before the next gate review cycle.

This prompt is designed to be called after test suites complete and canary data is collected, but before traffic is shifted to the new system prompt version. It functions as a deterministic gate in your CI/CD pipeline, not a continuous monitoring tool. The full JSON output should be stored as an immutable audit record in your release management system, capturing the decision, rationale, evidence snapshot, and evaluator identity for every gate evaluation.

For CI/CD integration, parse the JSON response and use the decision field as the primary gate control. Only a value of GO should allow the deployment pipeline to proceed. If the decision is NEEDS_REVIEW, route the complete output to the designated sign-off roles listed in the response and pause the pipeline until manual approval is recorded. If the decision is NO_GO, block the deployment immediately and notify the on-call channel with the blockers array from the response. Every gate evaluation must be logged with a timestamp, the evaluator model identity, and a full evidence snapshot to support compliance review and post-incident analysis.

Do not use this prompt for real-time monitoring or continuous validation. It is a point-in-time release gate that evaluates a specific candidate system prompt version against collected test evidence. Running it repeatedly against the same candidate without new evidence will produce identical results. Wire it once per release candidate at the appropriate stage in your deployment pipeline, and treat the output as the authoritative go/no-go record for that version.