Post-Correction Instruction Adherence Verification Prompt

This prompt is for AI SREs and production engineers who have already applied a drift correction prompt to a long-running agent session and now need to confirm the fix actually worked. The job-to-be-done is producing a statistically grounded before/after comparison that proves instruction hierarchy alignment has been restored, not just assumed. The ideal user is someone managing agents in production where silent instruction decay causes quality degradation that isn't immediately visible in surface-level outputs. They need evidence, not intuition, before closing an incident or rolling back a correction.

Use this prompt when a correction has been applied and you need a structured adherence verification report. The required inputs are the original instruction hierarchy, the session trace before correction, the session trace after correction, and the specific correction prompt that was applied. The output should include per-layer adherence scores, a confidence interval on the improvement, identification of any instructions that remain partially degraded, and a recommended re-drift monitoring window based on the rate of decay observed. Do not use this prompt for initial drift detection—that's a separate workflow. Do not use it when the correction was a full context reset, since there's no before/after comparison to make. Do not use it in low-risk, non-production scenarios where a manual spot check is sufficient.

The verification must be rigorous because false confidence after a correction is worse than acknowledged drift. The prompt should force the model to cite specific evidence from the session traces for each adherence claim, not just report aggregate scores. If the correction only partially worked, the output must flag which instruction layers remain degraded and whether the residual drift is within acceptable thresholds. For high-risk domains—healthcare, finance, legal, safety-critical operations—the verification output should include a human review recommendation with specific items to check before the session is considered healthy. The next step after running this prompt is either closing the drift incident with the verification report as evidence, applying a secondary targeted correction for residual degradation, or escalating to a human operator if the correction failed to meet minimum adherence thresholds.

This prompt template is designed for SREs and AI ops engineers who have applied a correction prompt to a drifting agent and now need to confirm that the correction actually took hold. It produces a structured before/after adherence comparison with statistical confidence scoring and a recommended re-drift monitoring window. The template uses square-bracket placeholders for all variable inputs, making it straightforward to wire into an automated verification pipeline or a manual review workflow.

textCopy
You are an instruction adherence auditor. Your task is to compare agent behavior before and after a drift correction was applied, and determine whether the correction successfully restored alignment with the original instruction hierarchy.

## INPUTS

### Original Instruction Hierarchy
[ORIGINAL_INSTRUCTIONS]

### Pre-Correction Session Trace
[PRE_CORRECTION_TRACE]

### Correction Prompt Applied
[CORRECTION_PROMPT]

### Post-Correction Session Trace
[POST_CORRECTION_TRACE]

### Adherence Criteria
[ADHERENCE_CRITERIA]

### Risk Level
[RISK_LEVEL]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "correction_applied": "string summarizing the correction that was attempted",
  "adherence_comparison": {
    "pre_correction": {
      "overall_score": "number 0.0-1.0",
      "violations": [
        {
          "instruction_layer": "system | developer | user | tool | policy",
          "violation_description": "string",
          "severity": "critical | high | medium | low",
          "trace_evidence": "string citing specific turn or message"
        }
      ],
      "decayed_layers": ["list of instruction layers showing drift"]
    },
    "post_correction": {
      "overall_score": "number 0.0-1.0",
      "resolved_violations": ["list of previously violated items now compliant"],
      "unresolved_violations": ["list of violations that persist after correction"],
      "new_violations": ["list of violations introduced by the correction itself"]
    }
  },
  "correction_efficacy": {
    "held": "boolean indicating whether correction restored adherence",
    "confidence": "number 0.0-1.0 indicating statistical confidence in the assessment",
    "improvement_delta": "number representing score change from pre to post",
    "partial_recovery": "boolean indicating if some but not all violations resolved"
  },
  "re_drift_risk": {
    "estimated_monitoring_window_turns": "number of turns before re-check recommended",
    "risk_factors": ["list of factors that could cause re-drift"],
    "recommended_re_anchoring_frequency": "string describing how often to reassert instructions"
  },
  "recommendation": {
    "action": "accept_correction | re_correct | escalate | monitor",
    "rationale": "string explaining the recommendation",
    "if_re_correct": "specific instruction layers or violations to target in a follow-up correction"
  }
}

## CONSTRAINTS

- Compare behavior against the original instruction hierarchy, not against the correction prompt's intent.
- Cite specific turns, messages, or tool calls as evidence for every violation claimed.
- If the post-correction trace is shorter than 3 turns, flag confidence as low and recommend extended monitoring.
- For [RISK_LEVEL] of "high" or "critical", require human review regardless of confidence score.
- Do not assume correction success from surface-level compliance; check for subtle instruction priority inversions.
- If the correction introduced new violations, classify them separately from unresolved pre-existing violations.
- The monitoring window recommendation must account for session length, drift velocity observed pre-correction, and correction type.

To adapt this template, replace each square-bracket placeholder with your actual data. The [ORIGINAL_INSTRUCTIONS] should contain the full instruction hierarchy as it existed before drift occurred. [PRE_CORRECTION_TRACE] and [POST_CORRECTION_TRACE] should include the conversation turns, tool calls, and model outputs from before and after the correction was applied. [ADHERENCE_CRITERIA] defines what compliance looks like for your specific use case—this might include output format requirements, refusal boundaries, tool-use constraints, or persona consistency rules. [RISK_LEVEL] should be set to "low", "medium", "high", or "critical" based on the blast radius of continued drift. For automated pipelines, parse the JSON output and route "escalate" or "re_correct" recommendations to the appropriate workflow. Always log the full assessment for audit trails, especially when the recommendation is "accept_correction" but confidence is below 0.85.

This prompt is designed to be called immediately after an instruction drift correction prompt has been applied to a session. It should not be used as a standalone check; its value comes from comparing the model's behavior before and after the correction event. The harness must provide both the original instruction hierarchy, the correction prompt that was applied, and a sample of model outputs from before and after the correction. Without this before/after context, the prompt cannot produce a meaningful adherence comparison or statistical confidence score.

Integrate this prompt into your drift remediation workflow as a mandatory verification gate. After a correction prompt is issued, capture the next N model responses (recommend N=5-10 depending on session criticality) and feed them into this verifier alongside the pre-correction output sample. The prompt returns a structured JSON payload containing an adherence_restored boolean, a confidence_score (0-1), and a re_drift_monitoring_window_hours recommendation. Implement a programmatic check: if adherence_restored is false or confidence_score falls below your threshold (suggest 0.85 for high-risk domains), trigger a human review escalation or a fallback correction strategy. Log the full verification payload to your observability platform, keyed by session ID and correction event timestamp, to build a longitudinal view of correction efficacy.

For production reliability, wrap this prompt call in a retry loop with exponential backoff (max 3 attempts) to handle transient model unavailability. Validate the output schema strictly—if the JSON is malformed or missing required fields, treat it as a verification failure and escalate. The re_drift_monitoring_window_hours field is a model-generated recommendation, not a hard rule; use it as an input to your monitoring scheduler but apply your own operational constraints (e.g., never exceed a 24-hour maximum window for regulated workloads). Avoid using this prompt on sessions shorter than 10 turns, as the before/after comparison lacks sufficient signal. Pair this verifier with your existing trace-level adherence scoring to correlate the verification result with per-turn fidelity metrics.