Deprecated Instruction Cleanup Verification Prompt

This prompt is designed for platform teams who treat prompts as production code and need a definitive, automated final gate before closing a deprecation window. The core job-to-be-done is confirming that a deprecated instruction version has zero residual references across all active agent configurations, in-flight session stores, and fallback or rollback paths. The ideal user is an SRE, a release engineer, or a platform operator responsible for the cleanup phase of an instruction deprecation. You should have already completed the prerequisite steps: issuing a formal deprecation notice, draining or migrating active sessions to the new instruction version, and updating all primary configuration stores. This prompt does not perform the removal or migration; it verifies that those steps were fully effective and identifies any lingering risk before you declare the deprecation complete.

Use this prompt when you need a structured, evidence-backed report rather than a manual grep or a simple config check. It is appropriate when your system has multiple places where an instruction version ID could hide—such as a central agent config database, a Redis-backed session state store, a fallback chain defined in a deployment manifest, or a rollback snapshot in a CI/CD artifact repository. The prompt is designed to accept a list of these scan targets and a specific deprecated version identifier, then produce a verification report with a clear pass/fail status and a residual-risk inventory. For example, if you deprecated instruction-set/v2.3.1 and migrated all traffic to v2.4.0, you would provide the deprecated version string and a manifest of scan targets. The prompt will then flag any instance where v2.3.1 still appears, such as a sticky session in a long-running support chat or a fallback override in a regional deployment config.

Do not use this prompt if you are still in the active migration phase or if you have not yet attempted to remove the deprecated instructions. It is a verification tool, not a removal tool. It is also not a substitute for a migration dry-run or a compatibility check; use the dedicated Migration Dry-Run Simulation Prompt or the Instruction Compatibility Check Prompt for those earlier stages. If your system does not have a programmatic way to query session state or configuration, you will need to build that retrieval harness first—this prompt assumes the evidence is available to be scanned. Finally, if the deprecated instruction is tied to a regulated workflow that requires a formal audit trail, pair this prompt's output with the Instruction Audit and Traceability Prompt to produce a complete compliance record before closing the deprecation window.

The following prompt template is designed to be dropped into a verification pipeline after a deprecation window has closed. It instructs the model to scan provided configuration artifacts, session state inventories, and fallback definitions for any trace of a specified deprecated instruction. The template uses square-bracket placeholders that your application must populate before each run. Do not use this prompt for real-time session interception or as a guardrail during active conversations—it is a batch verification tool meant for post-rollout cleanup audits.

textCopy
You are a deprecated instruction cleanup verifier. Your task is to confirm that a specific deprecated instruction has been fully removed from all active agent configurations, session states, and fallback paths provided to you.

## DEPRECATED INSTRUCTION TO VERIFY
[DEPRECATED_INSTRUCTION_ID]
[DEPRECATED_INSTRUCTION_TEXT]

## ARTIFACTS TO SCAN
### Active Agent Configurations
[AGENT_CONFIGS]

### Active Session State Inventory
[SESSION_STATES]

### Fallback Path Definitions
[FALLBACK_PATHS]

## VERIFICATION CRITERIA
1. Search each artifact for the exact instruction text, its instruction ID, and semantically equivalent rules that would produce the same behavior.
2. Flag any artifact that still contains the deprecated instruction, a close variant, or a rule that would override the deprecation.
3. For each flagged artifact, identify the specific location (config key, session field, fallback rule name) and the residual text found.
4. Assess whether the residual presence is active (will execute) or inert (present in audit logs or comments only).

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "verification_id": "string",
  "deprecated_instruction_id": "string",
  "scan_timestamp": "string (ISO 8601)",
  "total_artifacts_scanned": number,
  "clean_artifacts": number,
  "residual_findings": [
    {
      "artifact_type": "agent_config | session_state | fallback_path",
      "artifact_identifier": "string",
      "location": "string",
      "residual_text": "string",
      "match_type": "exact | semantic_variant | override_risk",
      "active_status": "active | inert | uncertain",
      "remediation_suggestion": "string"
    }
  ],
  "overall_status": "clean | residual_found | uncertain",
  "risk_flags": ["string"]
}

## CONSTRAINTS
- Do not hallucinate findings. If no residual is found, return an empty residual_findings array and overall_status "clean".
- If you are uncertain about a match, set active_status to "uncertain" and add a risk_flag explaining why.
- Do not modify any artifact. This is a read-only verification scan.
- If an artifact is malformed or unreadable, flag it in risk_flags with the artifact identifier and reason.

To adapt this template, replace each placeholder with data from your configuration store, session database, and fallback registry. The [AGENT_CONFIGS] placeholder should receive serialized YAML or JSON blobs representing the current deployed configurations for every agent in scope. The [SESSION_STATES] placeholder expects a structured inventory of active session metadata—not full conversation transcripts—sufficient to identify which instruction versions are loaded. The [FALLBACK_PATHS] placeholder should contain the fallback rule definitions that would activate if a primary instruction is unavailable. Before wiring this into an automated pipeline, validate that the output JSON matches the schema exactly and add a post-processing step that quarantines any artifact flagged with active_status: "active" for immediate remediation.

This prompt is designed to be run as a scheduled verification job, not a one-off manual check. Wire it into your CI/CD or release pipeline so that every instruction version bump triggers a cleanup scan. The prompt expects a structured inventory of all active agent configs, session states, and fallback paths. Feed it a JSON or YAML manifest generated by your configuration management system—never paste raw configs by hand. The output is a machine-readable cleanup verification report that your deployment gate can consume directly.

Input assembly: Build the [CONFIG_MANIFEST] placeholder by querying your agent registry, feature flag store, and session state database. The manifest must include: agent_id, active_instruction_version, deprecated_instruction_versions, session_count, fallback_instruction_version, and last_verified_timestamp. For [DEPRECATION_POLICY], supply your organization's deprecation window rules (e.g., "versions deprecated >30 days must have zero active sessions"). Validation layer: Before the model sees the manifest, run a structural validator that confirms every required field is present and that version strings match your semver pattern. Reject malformed manifests at the application layer—don't make the prompt debug your data.

Model selection and retries: Use a model with strong structured output discipline (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature=0 and enforce the output schema with your model provider's structured output mode or a post-processing JSON schema validator. If the output fails schema validation, retry once with the validation error appended to [CONSTRAINTS]. If it fails twice, escalate to a human operator with the raw manifest and both failed attempts. Logging: Capture the full prompt, manifest, output, and validation result to your observability platform. Tag each run with instruction_version and cleanup_run_id for traceability. Human review gate: If the report flags any residual_risk: true entries, block the deployment and route the report to the platform team's review queue. Do not auto-resolve residual risks.

Tool integration: This prompt works best when paired with a configuration scanner tool that the model can call to verify its findings. Define a verify_config tool that accepts an agent_id and instruction_version, then returns the live config state. The prompt's [TOOLS] placeholder should include this tool definition. The model should use it to confirm suspected residual references before flagging them. Avoid: Do not give the model write access to your config store. This is a read-only verification prompt. Any cleanup actions must happen through your standard change management process, not through model-initiated tool calls.