System Prompt Deprecation Notice Prompt

Use this prompt when your platform team has already decided to retire an old system prompt policy version and needs to produce a structured, auditable deprecation notice for internal stakeholders, downstream API consumers, or product teams that depend on the current behavior. The prompt assumes the replacement version is ready and the deprecation decision is final. It is not a decision-support tool for whether to deprecate a policy, nor is it a general communication generator. Its sole job is to transform a set of structured inputs—version identifiers, timeline dates, migration instructions, and impact assessments—into a consistent, review-ready deprecation notice that engineering leads, product managers, and compliance reviewers can inspect before publication.

The ideal user is an AI platform engineer, release manager, or technical product manager responsible for policy lifecycle operations. You should have the following context ready before invoking this prompt: the deprecated version identifier, the replacement version identifier, the deprecation announcement date, the end-of-support date, the backward compatibility window, a migration path or upgrade guide, and a user impact summary. The prompt works best when these inputs are concrete and accurate. Vague timelines or missing migration steps will produce a notice that fails review. If you lack any of these inputs, resolve them before using this prompt. The output is designed to slot into existing change management workflows, not to replace the human judgment required to assess whether the deprecation is safe, timely, or complete.

Do not use this prompt for emergency security patches that require immediate, unversioned system prompt overrides—those belong in a hotfix workflow with incident linkage. Do not use it to announce experimental policy changes, A/B test variants, or canary rollouts where the deprecation decision is not yet final. Do not use it as a substitute for a policy changelog or a version diff analysis; those are separate artifacts with different audiences and structures. This prompt is also inappropriate when the deprecated policy version has no replacement, because the migration path field becomes a dead end that erodes stakeholder trust. If you need to communicate a policy rollback rather than a planned deprecation, use a rollback communication prompt that includes incident context and root cause analysis.

Before running this prompt, confirm that the deprecation has been approved through your team's policy change governance process. The prompt will produce a notice that includes a user impact assessment and upgrade instructions, which means any inaccuracies in your inputs will propagate directly into stakeholder-facing communications. After generation, route the output through human review—especially the migration path, support end date, and impact statements—before distribution. For high-risk policy changes affecting regulated workflows or safety-critical behaviors, pair this notice with a policy change risk assessment and a rollback decision prompt so that stakeholders understand not just what is changing, but what the fallback options are if the migration encounters problems.

This prompt is designed for platform teams that need to communicate the retirement of a system prompt version to downstream consumers, internal stakeholders, or automated pipelines. It takes structured inputs about the deprecated version, its replacement, migration timeline, and backward compatibility window, then produces a notice with user impact assessment and upgrade instructions. The output is intended to be machine-readable for integration into changelogs, notification systems, or automated migration tooling.

textCopy
You are a policy deprecation communication specialist for an AI platform team. Your task is to generate a structured deprecation notice for a system prompt version that is being retired.

## INPUTS
- Deprecated Version: [DEPRECATED_VERSION]
- Replacement Version: [REPLACEMENT_VERSION]
- Deprecation Announcement Date: [ANNOUNCEMENT_DATE]
- End-of-Support Date: [END_OF_SUPPORT_DATE]
- End-of-Life Date: [END_OF_LIFE_DATE]
- Backward Compatibility Window: [BACKWARD_COMPATIBILITY_WINDOW]
- Migration Path Summary: [MIGRATION_PATH_SUMMARY]
- Breaking Changes List: [BREAKING_CHANGES]
- User Impact Assessment: [USER_IMPACT_ASSESSMENT]
- Rollback Instructions: [ROLLBACK_INSTRUCTIONS]
- Support Contact: [SUPPORT_CONTACT]
- Additional Context: [ADDITIONAL_CONTEXT]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "notice_id": "string - unique identifier for this deprecation notice",
  "deprecated_version": "string - version being deprecated",
  "replacement_version": "string - recommended replacement version",
  "announcement_date": "string - ISO 8601 date when notice is issued",
  "end_of_support_date": "string - ISO 8601 date when support ends",
  "end_of_life_date": "string - ISO 8601 date when version is fully removed",
  "backward_compatibility_window": "string - duration or description of compatibility period",
  "migration_path": {
    "summary": "string - concise migration instructions",
    "steps": ["string - ordered migration step", "..."],
    "estimated_effort": "string - low/medium/high with brief justification"
  },
  "breaking_changes": [
    {
      "change": "string - description of breaking change",
      "affected_behavior": "string - what user-facing behavior changes",
      "mitigation": "string - how to handle the change during migration"
    }
  ],
  "user_impact_assessment": {
    "severity": "string - low/medium/high/critical",
    "affected_user_segments": ["string - user groups or use cases affected"],
    "expected_degradation": "string - what happens if users do not migrate"
  },
  "rollback_instructions": "string - steps to revert to previous version if migration fails",
  "support_contact": "string - team or channel for migration assistance",
  "faq": [
    {
      "question": "string - anticipated user question",
      "answer": "string - clear answer"
    }
  ]
}

## CONSTRAINTS
- All dates must be in ISO 8601 format (YYYY-MM-DD).
- The end_of_life_date must be after the end_of_support_date.
- If no replacement version exists, set replacement_version to null and explain why in migration_path.summary.
- Breaking changes list must be empty if there are none; do not fabricate changes.
- User impact severity must be justified by the content of breaking_changes and user_impact_assessment.
- FAQ must include at least one question addressing "What happens if I don't migrate?"
- Do not include speculative or unconfirmed information.
- If any input field is marked "UNKNOWN" or is empty, note it explicitly in the relevant output field rather than guessing.

## RISK LEVEL: [RISK_LEVEL]
- If RISK_LEVEL is "high" or "critical", add a "human_review_required" boolean field set to true and include an "approval_checklist" array with items that must be verified before publication.
- If RISK_LEVEL is "low" or "medium", set "human_review_required" to false.

Before executing this prompt, validate that all date fields are present and in correct format. If the deprecated version has active production traffic, set RISK_LEVEL to "high" and route the generated notice through a human approval step before publication. After generation, validate the output JSON against the schema, confirm that the FAQ includes the mandatory migration question, and verify that breaking changes are not fabricated when the input list is empty. Store the generated notice alongside the system prompt version history for audit trail completeness.

The System Prompt Deprecation Notice prompt is designed to be integrated into a policy change management pipeline, not used as a one-off manual task. When a platform team decides to retire an old policy version, this prompt should be invoked programmatically with structured inputs pulled from the system of record: the deprecated version identifier, the replacement version, the migration timeline, and the list of affected tenants or services. The prompt produces a draft deprecation notice, but the output must pass through validation, stakeholder review, and approval gates before it reaches end users or downstream systems.

Wire the prompt into an application by building a thin service wrapper that accepts a DeprecationRequest object with fields matching the prompt's placeholders: [DEPRECATED_VERSION], [REPLACEMENT_VERSION], [DEPRECATION_DATE], [END_OF_SUPPORT_DATE], [MIGRATION_PATH], [BACKWARD_COMPATIBILITY_WINDOW], [AFFECTED_SERVICES], and [USER_IMPACT_SUMMARY]. The service should validate inputs before calling the model—reject missing version identifiers, enforce ISO 8601 date formats, and confirm that the replacement version exists in the policy registry. After the model returns a draft, run a structural validator that checks for required sections: deprecation timeline, migration instructions, backward compatibility window, support end date, and user impact assessment. If any section is missing or the output contains unresolved placeholders, trigger a retry with a more constrained prompt or escalate for manual drafting.

For production deployment, log every deprecation notice generation event with the input parameters, model version, output draft, validation results, and reviewer identity. Store these records in an audit trail that compliance teams can query when reconstructing policy change history. Before the notice is published, route it through a human approval queue where a release manager or product owner confirms accuracy, completeness, and tone. The approval step should be blocking—no automated distribution until a human signs off. After approval, the notice can be injected into communication channels: email templates, dashboard banners, API deprecation headers, or changelog entries. Avoid wiring this prompt directly to customer-facing surfaces without the validation and review gates; a hallucinated deprecation date or incorrect migration path can cause real operational damage.