Policy Changelog Generation Prompt

This prompt is designed for AI platform teams and engineering leads who need to produce a structured, human-readable changelog from two versions of a system prompt. The core job is turning a raw diff of system instructions into a categorized, risk-rated, and stakeholder-ready document that explains what changed, why it matters, and who needs to act. Use this when you are managing a library of versioned system prompts and must maintain an audit trail for compliance reviews, incident postmortems, or release communication.

The prompt expects two primary inputs: a previous system prompt version and a current system prompt version. It works best when those versions are complete, self-contained instruction blocks with clear boundaries, not fragments or partial updates. The output is a structured changelog that categorizes each change by type (e.g., new constraint, removed capability, behavioral shift, tone adjustment), assigns a risk level, identifies affected behaviors, and optionally generates a stakeholder communication template. This is not a prompt for generating system instructions from scratch, nor is it a diff tool for code-level changes. It is a policy-aware analysis tool for teams that treat system prompts as living contracts.

Do not use this prompt when you need a real-time behavioral comparison between models, a token-level diff, or an automated CI/CD gate. Those tasks require different tools: behavioral test prompts for regression detection, diff analysis prompts for breaking change detection, and release gate prompts for deployment approval. This prompt is also insufficient on its own for regulated environments where every change must be traced to a specific authorized request. In those cases, pair the output with a human review step and link each changelog entry to an approved change ticket. The prompt produces a draft suitable for review, not a final compliance filing. Always validate that the changelog correctly identifies removed or altered refusal behaviors, as these are the most common source of silent production regressions.

This template is the core engine for turning raw system prompt diffs into a human-readable, categorized changelog. It is designed to be copied directly into your prompt management system, CI/CD pipeline, or internal tooling. The prompt instructs the model to act as a technical release analyst, comparing two versions of a system instruction set and producing a structured report that engineering leads, product managers, and compliance auditors can act on. Before using this template, ensure you have the full text of both the [PREVIOUS_SYSTEM_PROMPT] and [NEW_SYSTEM_PROMPT] available, along with any relevant [CHANGE_CONTEXT] such as linked tickets or incident reports.

textCopy
You are a technical release analyst responsible for documenting changes to an AI system's behavioral policy. Your task is to compare the provided [PREVIOUS_SYSTEM_PROMPT] and [NEW_SYSTEM_PROMPT] and generate a structured changelog.

## Inputs
- Previous System Prompt: [PREVIOUS_SYSTEM_PROMPT]
- New System Prompt: [NEW_SYSTEM_PROMPT]
- Change Context (e.g., ticket, incident): [CHANGE_CONTEXT]

## Instructions
1.  **Analyze the Diff:** Identify all additions, deletions, and modifications between the two prompts. Focus on semantic changes to behavioral rules, role boundaries, tool permissions, safety policies, and output formatting.
2.  **Categorize Each Change:** Classify every identified change into one of the following types:
    - `BREAKING`: Removes or restricts a previously allowed capability.
    - `BEHAVIORAL_SHIFT`: Alters tone, refusal style, or decision-making logic without removing a capability.
    - `ADDITION`: Introduces a new capability, policy, or constraint.
    - `CLARIFICATION`: Rewords an existing rule for precision without changing its intent.
    - `FIX`: Corrects a typo, formatting error, or logical contradiction.
3.  **Assess Risk:** For each change, assign a risk level (`HIGH`, `MEDIUM`, `LOW`) based on the potential for user-facing impact or safety regression.
4.  **Generate the Changelog:** Produce the output strictly according to the [OUTPUT_SCHEMA] below.

## Constraints
- [CONSTRAINTS]
- Do not invent changes that are not present in the diff.
- If no changes are detected, state this explicitly in the `summary` field.
- For `BREAKING` changes, you must include a `migration_note` for downstream consumers.

## Output Schema
[OUTPUT_SCHEMA]

To adapt this template for your environment, start by replacing the [OUTPUT_SCHEMA] placeholder with a concrete JSON schema that matches your downstream logging or documentation system. A recommended schema includes fields for version_id, release_date, summary, and a changes array where each object has category, risk_level, description, diff_snippet, and migration_note. The [CONSTRAINTS] placeholder is your lever for enforcing organizational policy, such as requiring a specific format for migration_note or flagging any change that touches a [RESTRICTED_KEYWORD] list. For high-risk deployments, add a final instruction that the model must output a human_review_required boolean set to true if any BREAKING change is detected, ensuring an extra approval gate is triggered in your implementation harness.

This prompt is designed to run as a post-diff step in a system prompt release pipeline. After a new policy version is committed to the version control system, the application should compute a structured diff between the previous and current system instruction files. The diff, along with metadata such as version tags, author, and timestamp, is injected into the [POLICY_DIFF] and [VERSION_METADATA] placeholders. The model then generates a structured changelog object that can be consumed by downstream notification systems, audit databases, and stakeholder communication tools. Do not run this prompt on every commit; trigger it only on tagged releases or merge events to the main policy branch to avoid noise.

The implementation harness must enforce a strict output contract. Wrap the model call in a validation layer that checks for the required JSON schema fields: change_id, version, change_categories, risk_level, affected_behaviors, and stakeholder_summary. If the model returns malformed JSON or missing required fields, implement a single retry with the validation error message injected into the [PREVIOUS_ERROR] placeholder. After two consecutive failures, escalate to a human reviewer via a ticket in the policy review queue rather than entering an infinite retry loop. Log every generation attempt, including the raw prompt, model response, validation result, and retry count, to an observability platform for trace analysis.

For high-risk policy changes—those where the model assigns a risk_level of high or critical—the harness must block automatic distribution of the changelog. Instead, route the generated changelog to a human approval step where a policy owner can review the categorized changes, adjust the risk classification, and edit the stakeholder summary before publication. Use a feature flag or deployment gate to hold the changelog in a pending_review state. Once approved, the harness should publish the changelog to the designated channels: internal documentation, stakeholder email lists, and the audit trail database. Never auto-publish changelogs for breaking changes or safety-critical policy modifications without explicit human sign-off.