Policy Reinforcement Prompt After Drift Detection

This prompt is a surgical correction tool for production SREs and AI ops engineers, not a diagnostic instrument. It is designed to be deployed after a drift detection harness—such as a session instruction drift detection prompt or an automated integrity scan—has already identified which specific policy layers, refusal boundaries, or output contracts have decayed in a long-running agent session. The core job-to-be-done is to halt silent quality degradation by reasserting the original instruction hierarchy without resetting the session's accumulated context, which would disrupt the user experience and lose valuable state. The ideal user is an engineer on-call who has a confirmed drift report, the original system instructions, and the session context where the decay occurred, and who needs to measure whether the correction actually worked.

You must not use this prompt as a drift detection mechanism itself. If you are unsure whether drift has occurred, you should first run a diagnostic prompt like the 'Session Instruction Drift Detection Prompt Template' to produce a structured assessment with severity classification. Using this reinforcement prompt without a confirmed diagnosis risks over-correcting a stable agent, which can introduce unnecessary rigidity, break legitimate adaptive behaviors, or confuse the model with conflicting instructions. The prompt requires three concrete inputs to function: the original system instructions that define the intended policy hierarchy, a drift detection report that specifies which layers are failing and with what severity, and the recent session context showing the decay. Without these, the prompt cannot produce a targeted correction or a meaningful before/after adherence score.

After executing this prompt, your next step is to run a post-correction verification, such as the 'Post-Correction Instruction Adherence Verification Prompt,' to confirm the correction held with statistical confidence. Do not assume the first reinforcement attempt succeeded. In high-risk or regulated domains, the corrected session should be flagged for human review before it continues serving users. The before/after adherence scoring framework this prompt produces is your primary metric for deciding whether to release the session back into production, escalate for manual intervention, or terminate and restart the session with a fresh context window.

This template produces a targeted correction prompt designed to be injected into a session where drift has been detected. It does not reset the conversation. Instead, it re-anchors the model to the original policy hierarchy by restating the specific rules that have decayed, along with the evidence of their violation. The prompt is structured to be inserted as a high-priority system-level message, overriding any contradictory patterns the model has learned from recent turns.

textCopy
SYSTEM INSTRUCTION REINFORCEMENT — PRIORITY OVERRIDE

The following instructions override any conflicting patterns from recent conversation turns. You are being re-anchored to your original policy contract.

[DRIFT_SEVERITY]: [CRITICAL | HIGH | MEDIUM]
[DETECTION_TIMESTAMP]: [ISO_8601_TIMESTAMP]

## REASSERTED POLICY LAYERS

[POLICY_LAYER_1_NAME]
- Rule: [POLICY_1_RULE_STATEMENT]
- Violation Evidence (last [N] turns): [EVIDENCE_1]
- Expected Behavior: [EXPECTED_BEHAVIOR_1]

[POLICY_LAYER_2_NAME]
- Rule: [POLICY_2_RULE_STATEMENT]
- Violation Evidence (last [N] turns): [EVIDENCE_2]
- Expected Behavior: [EXPECTED_BEHAVIOR_2]

## REFUSAL BOUNDARIES

The following refusal boundaries are now reasserted with maximum priority:

[REFUSAL_BOUNDARY_1]
- Trigger Condition: [CONDITION_1]
- Required Response: [REFUSAL_RESPONSE_1]
- Safe Alternative (if applicable): [ALTERNATIVE_1]

[REFUSAL_BOUNDARY_2]
- Trigger Condition: [CONDITION_2]
- Required Response: [REFUSAL_RESPONSE_2]
- Safe Alternative (if applicable): [ALTERNATIVE_2]

## OUTPUT CONTRACT

Your outputs must conform to the following contract. Any deviation is a policy violation:

- Format: [OUTPUT_FORMAT]
- Schema: [OUTPUT_SCHEMA]
- Tone: [TONE_CONSTRAINT]
- Citation Requirement: [CITATION_RULE]
- Prohibited Content: [PROHIBITED_CONTENT_LIST]

## VERIFICATION INSTRUCTION

Before responding to the next user message, confirm internally:
1. Which policy layers were violated in the last [N] turns.
2. That your next response will comply with all reasserted rules above.
3. That you will not repeat the violation patterns listed in the evidence fields.

Do not output this verification. Proceed to the user's next message with full compliance.

Adapt this template by filling only the policy layers and boundaries that the drift detection system flagged as violated. Do not reassert rules that are still holding—over-correction can cause the model to become overly restrictive or confused. The [DRIFT_SEVERITY] field should match the output of your drift detection prompt so that downstream monitoring can correlate correction events with their triggers. After injecting this prompt, run a post-correction adherence verification to confirm the correction took effect before resuming normal operation.

The Policy Reinforcement Prompt is not a one-off fix; it is a recovery step inside a larger AI ops workflow. After a drift detection prompt has confirmed which instruction layers have decayed and produced a structured drift report, the reinforcement prompt is assembled with the original policy contract, the specific violations, and the session context that needs correction. The harness should treat this as a corrective action with a verification gate: apply the reinforcement prompt, then immediately run a post-correction adherence check to confirm the fix held before returning control to the user or agent loop.

The implementation loop follows a clear sequence. First, the drift detection output is parsed to extract the affected_layers, violation_examples, and severity fields. These are injected into the reinforcement prompt's [DRIFT_REPORT] placeholder alongside the original [POLICY_CONTRACT] and the [SESSION_CONTEXT] that triggered the drift. The model is called with a low temperature (0.0–0.2) to maximize deterministic correction. The output is validated against a schema that requires a reinforcement_statement string and a re_anchored_instructions object mapping each affected layer to its corrected directive. If validation fails, the harness retries once with an explicit format error message injected into the prompt. After a valid reinforcement output is produced, the harness immediately invokes the Post-Correction Instruction Adherence Verification Prompt using the same session context and the newly reinforced instructions. Only if the adherence score exceeds the configured threshold (typically ≥0.95 for production systems) does the harness apply the corrected instructions to the live session. If the score falls below threshold, the harness escalates to a human reviewer with the full drift report, reinforcement attempt, and verification failure details.

Logging and observability are critical here. Every reinforcement attempt should emit a structured event containing the drift_detection_id, reinforcement_prompt_version, model used, pre_correction_adherence_score, post_correction_adherence_score, and a correction_accepted boolean. These events feed into the instruction drift observability dashboard for trend analysis. For high-risk domains—such as healthcare, legal, or financial compliance—the harness must require human approval before applying the reinforced instructions, even if the automated verification passes. Configure a feature flag that gates auto-apply versus review-queue routing based on the [RISK_LEVEL] parameter. Avoid the temptation to silently apply corrections without verification; an ineffective reinforcement prompt that goes unvalidated will compound drift rather than resolve it.