Instruction Deprecation Reason Classification Prompt

Platform teams managing large instruction libraries need a systematic way to categorize why instructions are being deprecated. Manual classification across hundreds of rules creates inconsistency, misses multi-reason cases, and makes it impossible to analyze deprecation patterns over time. This prompt classifies a deprecated instruction into a predefined taxonomy, assigns confidence scores, and handles cases where multiple deprecation reasons apply simultaneously. Use this when you need structured, queryable deprecation metadata to drive migration planning, compliance reporting, or lifecycle analytics.

The prompt expects a deprecated instruction as input along with the taxonomy of valid deprecation reasons your organization recognizes. Common categories include: security vulnerability, regulatory change, business rule update, performance degradation, model behavior incompatibility, instruction conflict, scope narrowing, and replacement by a newer instruction. The output produces a JSON object with a primary classification, secondary classifications where applicable, confidence scores per classification, and a brief rationale grounded in the instruction text. This structured output feeds directly into deprecation dashboards, migration priority queues, and compliance audit trails.

Do not use this prompt for generating the deprecation notice itself or for deciding whether to deprecate; this prompt only classifies the reason after the deprecation decision is made. For notice generation, use the Deprecation Notice Generator prompt. For detecting deprecated instructions still active in production traces, use the Legacy Instruction Detection prompt. Pair this classification output with the Instruction Version Bump prompt to ensure the replacement instruction carries forward the deprecation rationale in its changelog. Always validate that the taxonomy you provide is complete before running bulk classification—missing categories will force the model into incorrect buckets and corrupt your analytics.

This prompt template is designed for platform teams that treat prompts as production code and need structured deprecation records. It accepts an instruction block and its deprecation context, then classifies the reason against a predefined taxonomy. The output includes the primary reason, any secondary reasons, a confidence score, and a concise rationale. Replace each square-bracket placeholder with your actual data before sending the prompt to the model.

textCopy
You are an instruction lifecycle auditor for a production AI platform. Your job is to classify why a system instruction is being deprecated.

## TAXONOMY
Use ONLY the following deprecation reason categories:
- SECURITY_VULNERABILITY: The instruction creates an injection risk, data leak, or unsafe behavior.
- POLICY_CHANGE: A legal, compliance, or organizational policy change requires the instruction to be removed or replaced.
- BEHAVIORAL_DRIFT: The instruction causes inconsistent, unpredictable, or degraded model behavior in production.
- OBSOLETE_FUNCTIONALITY: The feature or capability the instruction governed no longer exists.
- PERFORMANCE_DEGRADATION: The instruction increases latency, token usage, or cost without proportional value.
- CONFLICT_WITH_NEW_INSTRUCTION: A newer instruction supersedes or contradicts this one.
- USER_EXPERIENCE_ISSUE: The instruction causes poor user-facing behavior, tone problems, or refusal errors.
- MAINTENANCE_SIMPLIFICATION: The instruction is being removed to reduce prompt complexity without functional loss.
- OTHER: The reason does not fit any category above. Use sparingly.

## INPUT
[INSTRUCTION_TEXT]

[DEPRECATION_CONTEXT]

## OUTPUT_SCHEMA
Return ONLY valid JSON matching this schema:
{
  "primary_reason": "<TAXONOMY_CATEGORY>",
  "secondary_reasons": ["<TAXONOMY_CATEGORY>"],
  "confidence": <float between 0.0 and 1.0>,
  "rationale": "<One to three sentences explaining the classification. Reference specific parts of the instruction or deprecation context.>"
}

## CONSTRAINTS
- If multiple reasons apply, put the strongest in primary_reason and list others in secondary_reasons.
- Set confidence below 0.7 if the evidence is ambiguous. Never claim 1.0 unless the reason is explicitly stated.
- If the deprecation context is empty or uninformative, set confidence to 0.0 and primary_reason to OTHER.
- Do not invent reasons not present in the input.
- The rationale must cite evidence from [INSTRUCTION_TEXT] or [DEPRECATION_CONTEXT].

Adaptation guidance: Replace [INSTRUCTION_TEXT] with the full text of the deprecated instruction. Replace [DEPRECATION_CONTEXT] with any accompanying notes, migration plans, incident reports, or team comments that explain why the instruction is being removed. If no context exists, pass an empty string or a note like "No deprecation context provided." The taxonomy can be extended with additional categories, but keep the list closed to prevent the model from inventing ad-hoc labels. For high-risk domains such as healthcare or finance, add a [RISK_LEVEL] placeholder and require human review when confidence is below 0.8 or the primary reason is SECURITY_VULNERABILITY.

Next steps: After classification, feed the output into your instruction versioning system to populate deprecation metadata. Use the confidence score to decide whether the classification needs human review before the deprecation notice is published. If secondary reasons are present, consider whether the replacement instruction must address multiple root causes. For production pipelines, validate the JSON schema before writing the classification to your instruction registry.

This prompt is designed to be called programmatically as part of a CI/CD or governance pipeline, not as a one-off chat interaction. The typical integration point is a pre-commit hook, a pull request check, or a batch job that scans an instruction library for entries flagged as deprecated. The application layer should supply the instruction text, its current lifecycle stage, and the target taxonomy as structured inputs. The model's classification output is then used to auto-populate deprecation notices, route the deprecation for the correct review workflow (e.g., legal, product, or engineering), and update the instruction's metadata in the system of record.

To wire this in, build a thin service wrapper that accepts an instruction record, injects it into the prompt template's [INSTRUCTION_TEXT], [CURRENT_LIFECYCLE_STAGE], and [DEPRECATION_TAXONOMY] placeholders, and calls a capable but cost-effective model like GPT-4o-mini or Claude 3.5 Haiku. The response must be validated against the [OUTPUT_SCHEMA] before ingestion. A strict JSON schema validator should check for the presence of primary_reason, secondary_reasons, confidence_score, and rationale_summary. If validation fails, implement a single retry with the error message injected as additional [CONSTRAINTS] context. For high-risk or regulated instruction sets (e.g., safety policies, compliance rules), route classifications with a confidence_score below 0.85 to a human review queue. Log every classification attempt—including the model, prompt version, input hash, and raw output—to an audit table for traceability and future model regression testing.

Avoid using this prompt for real-time, user-facing deprecation decisions. It is a batch or event-driven classification tool. Do not bypass the validation layer; malformed JSON from the model will break downstream automation. The taxonomy itself should be versioned and stored as a configuration object, not hardcoded into the prompt, so that adding a new deprecation reason (e.g., vendor_end_of_life) does not require a prompt rewrite. Next, integrate the validated output into your deprecation notice generator and session migration risk scorer to close the loop from detection to action.