Instruction Lifecycle Deprecation Audit Prompt

Platform teams managing instruction version rollouts need to prove that deprecated rules are no longer influencing active sessions. This prompt scans conversation traces to identify sessions still governed by old instruction versions, assesses the compatibility risk of migrating them, and generates structured evidence for audit and change management workflows. Use it before decommissioning an instruction version, during a phased rollout, or when an auditor requires proof that a policy change has taken effect across all live sessions.

The ideal user is an AI platform engineer, SRE, or governance lead responsible for production instruction lifecycles. Required context includes a list of active session traces, the deprecated instruction version identifier, the replacement instruction version, and a compatibility policy that defines what constitutes a safe migration. The prompt is designed for batch processing of session traces, not real-time interception. It expects traces that include per-turn instruction metadata—if your logging doesn't capture which instruction version was active at each turn, you'll need to instrument that first before this prompt can produce reliable evidence.

Do not use this prompt for real-time instruction enforcement, for debugging a single bad output, or for detecting prompt injection attacks. It is not a guardrail and does not block deprecated instructions from being used—it audits after the fact. For real-time enforcement, use a routing layer that checks instruction version before model invocation. For single-output debugging, use the Decision Provenance Extraction Prompt. For injection detection, use the Instruction Injection Detection Audit Prompt. This prompt is also not a replacement for a proper feature flag or canary rollout system; it provides evidence for your change management process, not the mechanism for controlling the rollout itself.

This prompt template is the core of the Instruction Lifecycle Deprecation Audit Playbook. It is designed to be executed against a batch of active conversation sessions or agent traces. The prompt instructs the model to act as an audit engine: it must identify sessions still governed by deprecated instruction versions, assess the compatibility risk of continuing with those old rules, and produce structured evidence that the deprecated instructions are no longer influencing decisions after migration. Before using this template, you must have a registry of instruction versions with their deprecation status, a set of session traces, and a clear definition of what constitutes a 'deprecated instruction' in your system. This prompt is not a real-time guard; it is a post-hoc audit and migration planning tool.

textCopy
You are an Instruction Lifecycle Auditor. Your task is to analyze a set of active conversation sessions and determine which sessions are still governed by deprecated system instructions. You will assess the risk of continued operation under these deprecated rules and generate a migration evidence report.

## Input Data
- Session Traces: [SESSION_TRACES]
- Instruction Version Registry: [INSTRUCTION_REGISTRY]
- Deprecation Policy: [DEPRECATION_POLICY]
- Current Active Instruction Set: [ACTIVE_INSTRUCTIONS]
- Risk Assessment Criteria: [RISK_CRITERIA]

## Audit Steps
1. For each session in [SESSION_TRACES], extract the instruction version identifier active at the start of the session.
2. Cross-reference this identifier against the [INSTRUCTION_REGISTRY] to determine if the version is marked as 'deprecated'.
3. If a session is using a deprecated version, analyze the session trace to identify any model decisions, tool calls, or outputs that were directly governed by a rule that has changed or been removed in the [ACTIVE_INSTRUCTIONS].
4. For each identified decision, assess the compatibility risk based on [RISK_CRITERIA]. Classify the risk as 'LOW', 'MEDIUM', or 'HIGH'.
5. Generate a migration evidence record for each high-risk session, proving that the deprecated rule is no longer active after migration.

## Output Schema
Return a single JSON object with the following structure:
{
  "audit_timestamp": "string (ISO 8601)",
  "deprecated_instruction_version": "string",
  "sessions_audited": "number",
  "sessions_using_deprecated_version": "number",
  "findings": [
    {
      "session_id": "string",
      "deprecated_rule_id": "string",
      "deprecated_rule_text": "string",
      "affected_decision_turn": "number",
      "affected_decision_summary": "string",
      "compatibility_risk": "LOW | MEDIUM | HIGH",
      "risk_rationale": "string",
      "migration_evidence": "string (explain how the decision would differ under active instructions)"
    }
  ],
  "sessions_requiring_forced_migration": ["session_id"],
  "overall_recommendation": "string"
}

## Constraints
- Only flag a session if the deprecated rule had a material impact on a decision. Do not flag sessions where the deprecated rule was present but never triggered.
- For 'HIGH' risk findings, the migration_evidence field is mandatory and must cite the specific new rule from [ACTIVE_INSTRUCTIONS] that replaces the deprecated one.
- If a session's trace is incomplete or the instruction version cannot be determined, flag it as 'UNVERIFIED' and exclude it from risk counts.
- Do not invent instruction versions or rules not present in the provided registries.

To adapt this template for your environment, replace the square-bracket placeholders with production data. [SESSION_TRACES] should be a serialized array of conversation objects, each containing a session ID, a version identifier, and the full turn-by-turn trace. [INSTRUCTION_REGISTRY] is your source of truth for instruction versions, their statuses, and their rule definitions. [DEPRECATION_POLICY] defines the criteria for when a version is considered deprecated in your organization. [ACTIVE_INSTRUCTIONS] is the current, canonical instruction set that should be governing all live traffic. [RISK_CRITERIA] should be a clear, machine-readable definition of what constitutes a low, medium, or high compatibility risk in your specific application context—for example, a high risk might be defined as any change to a data-handling or authentication rule. The output schema is designed to be ingested by a downstream migration dashboard or ticketing system. If you are auditing sessions at scale, batch the sessions and run this prompt in parallel, then aggregate the results. Always have a human review findings classified as 'HIGH' risk before triggering a forced session migration.

The Instruction Lifecycle Deprecation Audit Prompt is not a one-off analysis tool; it is a component in a continuous instruction governance pipeline. Platform teams should integrate this prompt into a scheduled job or an event-driven workflow that triggers whenever a new instruction version is promoted to production. The harness must supply the prompt with a list of active session IDs, the deprecated instruction version identifier, the replacement instruction version identifier, and the full text of both instruction sets. The model's output—a structured JSON array of impacted sessions with compatibility risk scores and migration evidence—must be validated before any downstream action is taken.

Start by building a thin orchestration layer that queries your session store for all active conversations and filters for those whose instruction_version metadata matches the deprecated version. For each candidate session, extract the conversation trace and construct the prompt's [SESSION_TRACES] input as a JSON array of objects, each containing a session_id, instruction_version, and messages array. Pass this alongside the [DEPRECATED_INSTRUCTION] and [REPLACEMENT_INSTRUCTION] blocks. Choose a model with strong structured output adherence—GPT-4o or Claude 3.5 Sonnet with JSON mode enabled are good defaults. Set temperature=0 to maximize reproducibility for audit evidence. Wrap the call in a retry loop with exponential backoff (max 3 attempts) and validate the response against a strict JSON schema that checks for required fields: session_id, deprecated_rules_active, compatibility_risk (enum: low, medium, high, critical), migration_evidence, and recommended_action. Reject any response that fails schema validation and log the failure for manual triage.

After validation, route sessions based on risk level. Low-risk sessions can be automatically migrated by updating their instruction_version metadata to the replacement version. Medium-risk sessions should trigger a notification to the session owner with the migration evidence attached. High-risk and critical-risk sessions must enter a human review queue where an operator examines the conversation trace and the model's compatibility assessment before approving or rejecting migration. Log every decision—auto-migration, notification, or human review—with a timestamp, operator identity (where applicable), and the full prompt input and output. This audit log becomes the evidence packet for proving that deprecated instructions are no longer influencing active decisions. Do not allow the model to directly execute migration; the harness must retain final authority over session state changes.