Instruction Re-Injection Trigger Prompt

This prompt is for AI engineers and platform teams who manage long-running, regulated, or brand-sensitive assistant sessions where system instructions are at risk of being truncated or diluted by the context window. The core job-to-be-done is to programmatically decide when and which critical instructions, compliance rules, or output contracts must be re-inserted into the active context to prevent policy drift. The ideal user is someone building a production AI harness—a chat application, copilot, or agent—who needs an automated gate, not a manual spot-check. You need this when your session length, token budget, or retrieval-augmented generation (RAG) context pushes the original system prompt out of the model's attention, and the cost of a policy violation is high.

Do not use this prompt for short, stateless single-turn tasks or for sessions where the entire instruction set comfortably fits within the context window with room to spare. It is also the wrong tool if you are trying to fix a poorly written system prompt; this prompt assumes the original instructions are well-formed and the problem is purely one of context window economics. The prompt requires as input the original system instructions, a summary of the recent conversation turns, and the current context window budget. It is designed to be called by your application logic—for example, a pre-processing step before each model call or a periodic check every N turns—not as a one-off debugging aid.

After using this prompt, your application should act on the structured output: either injecting the recommended instructions with the assigned priority ranking or logging a decision to defer. The next step is to wire this decision into your prompt assembly pipeline, ensuring the re-injected instructions are placed in a high-priority position within the system message. Avoid treating this as a simple text classifier; the value is in the priority ranking and the explicit rationale, which you should log for auditability and use to tune your re-injection frequency.

The prompt below is designed to be called periodically during a long-running assistant session—typically when the context window approaches a usage threshold or when a turn count limit is reached. It evaluates the current conversation state, the remaining visibility of critical system instructions, and the risk of policy drift. The output is a structured re-injection decision with a priority-ranked list of instructions that must be re-inserted. Adapt the placeholders to match your specific policy documents, context window budget, and risk tolerance.

textCopy
You are an instruction integrity monitor for a regulated assistant. Your job is to decide whether critical system instructions, compliance rules, or output contracts must be re-injected into the context window because they are about to be truncated or diluted.

[CONTEXT_WINDOW_BUDGET]
[TURN_HISTORY_SUMMARY]
[ACTIVE_POLICIES]
[OUTPUT_CONTRACT]
[RISK_LEVEL]

Analyze the current session state and determine:
1. Which critical instructions are still visible and enforceable in the remaining context window.
2. Which instructions are at risk of truncation within the next [TURN_THRESHOLD] turns.
3. Whether instruction drift, tone erosion, or policy violation is already detectable in recent assistant outputs.
4. The priority order for re-injection if multiple instructions are at risk.

Produce a structured re-injection decision in the following format:

{
  "re_injection_required": true|false,
  "urgency": "immediate"|"next_turn"|"within_3_turns"|"not_required",
  "at_risk_instructions": [
    {
      "instruction_id": "string",
      "instruction_summary": "string",
      "truncation_risk": "high"|"medium"|"low",
      "drift_detected": true|false,
      "drift_evidence": "string or null",
      "re_injection_priority": 1-10,
      "re_injection_text": "exact text to re-insert"
    }
  ],
  "still_enforced_instructions": ["instruction_id"],
  "recommended_insertion_point": "before_next_user_turn"|"after_current_response"|"as_system_prefix",
  "token_estimate_for_re_injection": <integer>,
  "rationale": "string"
}

Constraints:
- Do not recommend re-injection for instructions that are still fully visible and enforced.
- Prioritize compliance and safety instructions over tone or formatting instructions.
- If drift is already detected, set urgency to "immediate."
- The re_injection_text field must contain the exact text to re-insert, not a summary.
- If no re-injection is required, return an empty at_risk_instructions array and set urgency to "not_required."

Adaptation guidance: Replace [CONTEXT_WINDOW_BUDGET] with your model's context limit and current usage. [TURN_HISTORY_SUMMARY] should be a compressed summary of recent turns, not the full history. [ACTIVE_POLICIES] is the set of system instructions, compliance rules, and behavioral contracts currently in effect. [OUTPUT_CONTRACT] defines the expected response format. [RISK_LEVEL] should reflect the domain's tolerance for instruction drift—use "high" for regulated industries, "medium" for brand-sensitive applications, and "low" for experimental deployments. [TURN_THRESHOLD] is the number of turns before you expect truncation to occur.

Before deploying this prompt in production, test it against sessions with known drift patterns and verify that the re-injection decision matches your manual assessment. Common failure modes include: recommending re-injection too early and wasting context budget, failing to detect subtle tone drift, and producing re-injection text that is too verbose for the remaining window. Run this prompt at a cadence that balances protection against token cost—every 10-15 turns is a reasonable starting point for most deployments.

The Instruction Re-Injection Trigger Prompt is not a user-facing prompt. It is a control-plane prompt that runs inside your application's context management layer, typically invoked by a context window monitor or a turn-counting middleware component. Its job is to decide whether system instructions, compliance rules, or output contracts must be re-inserted into the active context window because they are about to be truncated, diluted, or evicted by newer turns. The prompt should be called before each model request when the remaining context budget falls below a configured threshold, or on a fixed turn interval such as every N user-assistant exchanges. The output is a structured re-injection decision with priority rankings, not a user-visible message.

Wire this prompt into your application as a pre-flight check in the prompt assembly pipeline. Before assembling the final model request, call the re-injection trigger with the current context window contents, the original system instructions, the session's policy contract, and the estimated token distance to truncation. Parse the JSON output and use the re_inject boolean and priority_ranking array to decide which instruction blocks to prepend to the next request. Implement a validation layer that rejects any trigger output where re_inject is true but priority_ranking is empty, or where ranked instructions reference identifiers not present in the original policy contract. Log every trigger invocation with the decision, token budget remaining, and which instructions were re-injected. For high-compliance domains, store these logs as audit evidence that instruction adherence was actively managed throughout the session.

Model choice matters here. This prompt requires strict JSON output adherence and low latency, so prefer a fast, instruction-following model such as gpt-4o-mini, claude-3-haiku, or a fine-tuned small model if you have sufficient training data. Avoid using your largest, most expensive model for this control-plane task unless latency is not a concern. Implement a retry strategy with a maximum of two retries on JSON parse failure, using a stricter output format reminder in the retry prompt. If the trigger consistently fails or returns ambiguous rankings, fall back to a deterministic rule: re-inject the top-priority instruction block when context budget drops below 20% of the window size. Never let a failed trigger invocation silently proceed without re-injection in regulated or safety-critical deployments. The safe default is to re-inject, not to skip.