System Prompt Version Lock Decision Prompt

Engineering leads and AI release managers face a critical decision point when system instructions have been iterated on and tested: lock the version to enforce stability, or continue iteration to close known gaps. This prompt produces a structured decision record that weighs stability requirements, regression risk, iteration velocity, and stakeholder input quality. Use this prompt when you have a candidate system prompt version, test results, and a list of known limitations. Do not use this prompt for initial prompt design or for evaluating individual prompt components in isolation.

The prompt requires concrete inputs to function: a candidate system prompt version identifier, a summary of regression test results with pass/fail counts, a catalog of known behavioral gaps or edge cases, stakeholder feedback from safety, product, and engineering, and the current iteration velocity measured in changes per week. Without these inputs, the decision record will be speculative. The prompt is designed to force explicit trade-offs—it will ask you to rate stability risk, quantify the cost of delaying a freeze, and identify which stakeholders have not yet weighed in. This is not a lightweight pros-and-cons list; it is a structured decision artifact suitable for a change advisory board or release governance process.

Avoid using this prompt when the system prompt is still in early exploration, when no regression test suite exists, or when the team has not yet defined what 'stable' means for their use case. If you lack a behavioral baseline or haven't run the same prompt across multiple model instances to check consistency, run the Production Behavior Baseline Capture Prompt and the Pre-Freeze Regression Test Suite Generation Prompt first. This prompt assumes you are at the decision gate, not still gathering evidence. If you use it too early, it will produce a low-confidence record that highlights missing inputs rather than making a clear recommendation—which is itself a useful signal, but not the intended workflow.

This template is designed to be pasted directly into your AI harness, LLM playground, or prompt management system. It forces a structured decision record by weighing stability requirements against known gaps, rather than producing a simple yes/no answer. Replace each square-bracket placeholder with your actual data before execution. The prompt expects concrete evidence—test results, behavioral metrics, stakeholder input—and will flag when critical information is missing.

codeCopy
You are an AI release manager evaluating whether to lock the current system prompt version or continue iteration. Your output must be a structured decision record, not a conversational recommendation.

## SYSTEM PROMPT UNDER REVIEW
[SYSTEM_PROMPT_TEXT]

## VERSION INFORMATION
- Current version: [CURRENT_VERSION]
- Previous locked version (if any): [PREVIOUS_LOCKED_VERSION]
- Iteration count since last lock: [ITERATION_COUNT]
- Days since last lock: [DAYS_SINCE_LAST_LOCK]

## STABILITY EVIDENCE
- Behavioral consistency score across [RUN_COUNT] runs: [CONSISTENCY_SCORE]/100
- Edge case coverage percentage: [EDGE_CASE_COVERAGE]%
- Regression test pass rate: [REGRESSION_PASS_RATE]%
- Production behavior baseline captured: [BASELINE_CAPTURED: true/false]
- Drift from baseline (if captured): [DRIFT_PERCENTAGE]%

## KNOWN GAPS
[List each known gap with severity (Critical/High/Medium/Low) and impact description]
[GAP_1]
[GAP_2]
[GAP_3]

## STAKEHOLDER INPUT
- Engineering lead assessment: [ENGINEERING_ASSESSMENT]
- Product owner assessment: [PRODUCT_ASSESSMENT]
- Safety/Compliance assessment: [SAFETY_ASSESSMENT]
- QA lead assessment: [QA_ASSESSMENT]

## CONSTRAINTS
- Release deadline pressure: [DEADLINE_PRESSURE: None/Low/Medium/High/Critical]
- Downstream dependency freeze requirements: [DOWNSTREAM_FREEZE_REQUIREMENTS]
- Regulatory compliance gate: [REGULATORY_GATE: true/false]
- Rollback capability available: [ROLLBACK_AVAILABLE: true/false]

## OUTPUT SCHEMA
Produce a JSON decision record with this exact structure:
{
  "decision": "LOCK" | "ITERATE" | "CONDITIONAL_LOCK",
  "confidence": 0.0-1.0,
  "rationale_summary": "string",
  "stability_assessment": {
    "score": 0-100,
    "strengths": ["string"],
    "weaknesses": ["string"]
  },
  "gap_analysis": [
    {
      "gap": "string",
      "severity": "Critical" | "High" | "Medium" | "Low",
      "blocks_lock": true | false,
      "mitigation_if_locked": "string"
    }
  ],
  "stakeholder_alignment": {
    "aligned": true | false,
    "dissenting_views": ["string"],
    "unresolved_concerns": ["string"]
  },
  "conditions_for_lock": ["string"],
  "recommended_next_steps": ["string"],
  "risk_if_locked_now": "Low" | "Medium" | "High" | "Critical",
  "risk_if_delayed": "Low" | "Medium" | "High" | "Critical",
  "missing_information": ["string"],
  "exception_readiness": {
    "exception_policy_exists": true | false,
    "rollback_procedure_tested": true | false,
    "monitoring_configured": true | false
  }
}

## DECISION RULES
1. If any gap has severity "Critical" and blocks_lock is true, decision must not be "LOCK".
2. If stakeholder_alignment.aligned is false and unresolved_concerns contains safety or compliance items, decision must not be "LOCK".
3. If exception_readiness has any false values, decision must be "CONDITIONAL_LOCK" at most.
4. If missing_information is non-empty, flag it explicitly and reduce confidence.
5. If regulatory_gate is true and any compliance concern is unresolved, decision must be "ITERATE".
6. Weigh risk_if_locked_now against risk_if_delayed explicitly in rationale_summary.

## VALIDATION
Before outputting, verify:
- All required fields in OUTPUT_SCHEMA are present.
- decision value is consistent with gap_analysis and stakeholder_alignment.
- confidence is justified by evidence completeness, not optimism.
- missing_information accurately reflects any placeholder left as [UNKNOWN] or [TBD].

To adapt this template, replace every bracketed placeholder with real data from your testing pipeline, stakeholder reviews, and operational readiness checks. If a placeholder cannot be filled, leave it as [UNKNOWN]—the prompt will flag it in missing_information. For high-stakes releases, run this prompt through your eval harness before presenting the output to a change advisory board. Never treat the model's decision as final without human review when risk_if_locked_now is High or Critical.

The System Prompt Version Lock Decision Prompt is designed to be integrated into an AI release management pipeline, not used as a one-off chat query. The prompt expects structured inputs about the current system prompt version, known gaps, stability metrics, and stakeholder positions. Before calling the model, assemble these inputs from your prompt registry, test run history, and stakeholder feedback channels. The output is a structured decision record that should be persisted alongside your prompt version history for auditability.

Implement this as a gated step in your CI/CD pipeline for prompt releases. The harness should: (1) fetch the current system prompt version, recent eval results, and open issues from your prompt management system; (2) populate the [CURRENT_VERSION], [STABILITY_METRICS], [KNOWN_GAPS], [STAKEHOLDER_INPUT], and [RELEASE_CONTEXT] placeholders; (3) call the model with a low temperature setting (0.1–0.3) to maximize decision consistency; (4) validate the output against the expected JSON schema before accepting it. If validation fails, retry once with the validation errors injected into the [CONSTRAINTS] field. If the second attempt also fails, escalate to a human release manager rather than silently proceeding with an unvalidated decision.

Log every decision run with the full input context, model response, validation result, and final lock/iterate outcome. Store these records in your prompt version history so that future audits can trace why a particular version was locked or iterated. For high-risk production systems, add a mandatory human approval step: the harness should post the structured decision record to a review queue and block the lock action until a designated release manager approves. The approval gate should check that all required stakeholder perspectives are represented in the [STAKEHOLDER_INPUT] field and that no high-severity gaps were dismissed without explicit justification. After approval, the lock action should tag the prompt version as frozen in your registry and trigger the downstream freeze documentation and monitoring setup workflows.