Instruction Freeze Stakeholder Sign-Off Prompt

This prompt is for AI release managers and platform engineers who need a formal, structured sign-off record before freezing system instructions. Freezing a system prompt without documented stakeholder approval creates audit gaps, operational risk, and downstream liability when frozen behavior causes production incidents. The prompt forces explicit conditions, concerns, and acceptance criteria from every required stakeholder group—safety, product, engineering, and compliance—producing a single, auditable artifact that proves organizational alignment before the freeze takes effect.

Use this prompt when the freeze decision is technically ready but needs organizational alignment. The ideal user has already completed behavioral consistency checks, regression testing, and edge case coverage audits. They have a candidate system prompt that is stable enough to freeze, and they need to gather structured approval from stakeholders who may have conflicting priorities. The prompt requires you to provide the candidate system instructions, a list of required stakeholder groups, any known risks or open issues, and the freeze timeline. It then produces a sign-off record with conditions, concerns, acceptance criteria, and a clear approval status for each stakeholder group. The output includes validation checks for missing perspectives and unaddressed objections, so you can identify gaps before the freeze proceeds.

Do not use this prompt for exploratory prompt iteration, informal team alignment, or when the system prompt is still undergoing active behavioral changes. It is not a collaboration tool for drafting instructions or a replacement for technical freeze readiness assessments. If you have not yet completed regression testing, edge case coverage audits, or behavioral drift baselining, use the sibling prompts for those tasks first. This prompt assumes the freeze is technically justified and focuses exclusively on the organizational sign-off layer. Using it prematurely will produce a sign-off record that masks unresolved technical risk, creating a false sense of security and undermining the audit trail you are trying to build.

The following prompt is designed to be pasted into your orchestration layer. It collects structured approval from safety, product, engineering, and compliance stakeholders before you freeze a system prompt. The output is a sign-off record that captures conditions, unresolved concerns, and explicit acceptance criteria. Replace every square-bracket placeholder with real values before execution. The prompt assumes you have already completed behavioral consistency checks, regression testing, and edge-case audits; it focuses on the human approval gate, not the technical validation gate.

textCopy
You are an AI release manager assistant responsible for collecting structured stakeholder sign-off before freezing a system prompt. Your output will be archived as an audit record.

## CONTEXT
System Prompt Name: [SYSTEM_PROMPT_NAME]
System Prompt Version: [VERSION_IDENTIFIER]
Freeze Request Date: [REQUEST_DATE]
Proposed Freeze Date: [FREEZE_DATE]

## INPUT
Below are the stakeholder perspectives, test results, and risk assessments collected before the freeze decision.

### Test Results Summary
[TEST_RESULTS_SUMMARY]

### Edge Case Coverage Report
[EDGE_CASE_COVERAGE_REPORT]

### Behavioral Drift Baseline
[BEHAVIORAL_DRIFT_BASELINE]

### Risk Assessment
[RISK_ASSESSMENT]

### Stakeholder Feedback
[STAKEHOLDER_FEEDBACK]

## REQUIRED STAKEHOLDER PERSPECTIVES
You must confirm that each of the following perspectives has been addressed. If a perspective is missing, flag it as a gap.
- Safety and policy compliance
- Product and user experience
- Engineering and operational reliability
- Legal and regulatory compliance (if applicable)
- Security and adversarial robustness

## OUTPUT SCHEMA
Return a valid JSON object with this exact structure:
{
  "freeze_decision": "APPROVED" | "CONDITIONAL" | "REJECTED",
  "stakeholder_sign_off": [
    {
      "role": "string",
      "name": "string",
      "approval_status": "APPROVED" | "CONDITIONAL" | "REJECTED" | "PENDING",
      "conditions": ["string"],
      "concerns": ["string"],
      "acceptance_criteria": ["string"],
      "signed_off_by": "string or null",
      "sign_off_date": "string or null"
    }
  ],
  "missing_perspectives": ["string"],
  "unresolved_objections": ["string"],
  "required_actions_before_freeze": ["string"],
  "post_freeze_monitoring_requirements": ["string"],
  "rollback_triggers": ["string"],
  "freeze_conditions_summary": "string",
  "overall_risk_rating": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
  "recommendation": "string"
}

## CONSTRAINTS
- Do not approve a freeze if any required perspective is missing or unaddressed.
- If any stakeholder has unresolved objections, the freeze decision must be CONDITIONAL or REJECTED.
- Every condition must have a corresponding acceptance criterion.
- Rollback triggers must be specific and measurable, not vague aspirations.
- If the risk rating is CRITICAL, the freeze decision cannot be APPROVED.
- Flag any stakeholder feedback that appears to be a rubber stamp without substantive engagement.
- Do not invent stakeholder names, dates, or approvals. Use null when information is absent.

## EXAMPLES
Example conditional approval:
{
  "freeze_decision": "CONDITIONAL",
  "stakeholder_sign_off": [
    {
      "role": "Safety Lead",
      "name": "Jane Smith",
      "approval_status": "CONDITIONAL",
      "conditions": ["Must add refusal for self-harm content before freeze"],
      "concerns": ["Current refusal rate for borderline cases is too low"],
      "acceptance_criteria": ["Refusal rate on safety eval set exceeds 95%"],
      "signed_off_by": "Jane Smith",
      "sign_off_date": "2025-06-15"
    }
  ],
  "missing_perspectives": [],
  "unresolved_objections": [],
  "required_actions_before_freeze": ["Implement self-harm refusal policy", "Re-run safety eval set"],
  "post_freeze_monitoring_requirements": ["Monitor refusal rate daily for 7 days post-freeze"],
  "rollback_triggers": ["Refusal rate drops below 90% for 2 consecutive hours"],
  "freeze_conditions_summary": "Freeze approved conditional on implementing self-harm refusal policy and passing safety eval threshold.",
  "overall_risk_rating": "MEDIUM",
  "recommendation": "Proceed with conditional freeze after required actions are completed and verified."
}

## TOOLS
None required. This is a structured reasoning task.

## RISK_LEVEL
HIGH. Incorrect freeze decisions can cause production incidents, safety violations, or compliance failures. The output will be used as an audit record.

Adapt this template by replacing the input placeholders with your actual test results, edge-case reports, drift baselines, risk assessments, and stakeholder feedback. If your organization requires additional stakeholder perspectives—such as data privacy, accessibility, or internationalization—add them to the REQUIRED STAKEHOLDER PERSPECTIVES section. The output schema is designed to be machine-readable for downstream audit systems, but the freeze_conditions_summary and recommendation fields also provide human-readable summaries for release managers and change advisory boards.

Before executing this prompt in a production workflow, validate that all input documents exist and are current. Stale test results or missing stakeholder feedback will produce a misleading sign-off record. Wire this prompt into a human-in-the-loop approval step: the model produces a structured recommendation, but a release manager must confirm the final freeze decision. Archive the full JSON output alongside your system prompt version history for auditability. If the model returns missing_perspectives or unresolved_objections, block the freeze pipeline until those gaps are closed.

The sign-off prompt is not a one-shot chat interaction. It should be embedded in a release management harness that enforces structured input collection, validates the completeness of the sign-off record, and persists an immutable audit trail. The harness acts as the gate between stakeholder input and the decision to freeze system instructions. Without it, sign-offs become informal, unverifiable, and legally weak.

Input collection should be handled by a form or structured API call that gathers the required fields before invoking the prompt: [SYSTEM_PROMPT_VERSION], [RELEASE_NOTES], [TEST_RESULTS_SUMMARY], [KNOWN_LIMITATIONS], and a list of [STAKEHOLDER_INPUTS] where each entry includes the stakeholder's role, approval status, conditions, concerns, and timestamp. The harness must validate that all required stakeholder roles (safety, product, engineering, compliance) are present before calling the model. If any role is missing, the harness should refuse to proceed and return a structured error indicating which perspectives are absent.

Model invocation should use a low-temperature setting (0.0–0.2) to maximize consistency in the sign-off record structure. The prompt expects a JSON output matching [OUTPUT_SCHEMA], so the harness must parse the response and validate it against the schema. If validation fails—missing fields, malformed JSON, or an approval_decision that contradicts individual stakeholder inputs—the harness should retry up to two times with the validation errors appended as additional context. After three failures, escalate to a human release manager with the raw output and validation log.

Audit logging is mandatory. Every invocation must write an immutable record containing: the full prompt with all inputs, the model response, the validation result, the retry count, the final sign-off decision, and a timestamp. Store this in an append-only log or database table keyed by [SYSTEM_PROMPT_VERSION]. This record serves as the evidence package for compliance reviews, incident investigations, and governance audits. Do not rely on chat history or model provider logs as your sole audit trail.

Human review is required when the prompt returns approval_decision: "CONDITIONAL" or when any stakeholder has unresolved concerns. The harness should route these cases to a review queue with the full sign-off record, highlight the blocking conditions, and require explicit human acknowledgment before the freeze can proceed. Automating the sign-off collection is safe; automating the final freeze decision without human confirmation is not. Wire the harness output into your CI/CD pipeline so that a "APPROVED" decision unblocks the freeze step, while any other outcome blocks it.