Instruction Drift SLA Compliance Monitoring Prompt

This playbook is for platform and SRE teams who have contractual or internal Service Level Agreements (SLAs) on instruction fidelity for long-running AI agents. When instruction drift causes a model to violate its defined role, policy, or output contract, you need a structured compliance report that maps each drift event to a specific SLA clause, determines if a breach occurred, and tracks remediation. This prompt ingests raw drift detection outputs, session traces, and your SLA definitions to produce an auditable compliance report with trend analysis for threshold calibration. Use this when an automated drift detector has already flagged anomalies and you need to operationalize the business and contractual impact.

Do not use this prompt as a real-time drift detector. It is designed for post-detection compliance analysis, not for identifying drift in live sessions. If you need to detect drift first, start with the Session Instruction Drift Detection Prompt Template or the Trace-Level Instruction Adherence Scoring Prompt before feeding results into this compliance workflow. This prompt also assumes you have defined SLA clauses with measurable thresholds—if your SLAs are still informal or qualitative, you will get vague reports that fail audit scrutiny. The prompt works best with structured SLA definitions that include specific metrics (e.g., 'role boundary violations must not exceed 2 per 100 turns'), measurement windows, and breach consequence tiers.

Before running this prompt, ensure you have three inputs ready: (1) the raw drift detection output from your monitoring system, including timestamps, severity scores, and affected instruction layers; (2) the relevant session traces or turn-level adherence scores that provide evidence for each flagged event; and (3) your SLA document with explicit clause identifiers, threshold values, and breach definitions. The prompt will fail silently or produce unreliable reports if any of these inputs are missing or poorly structured. For high-stakes compliance workflows, always route the final report through human review before it reaches external stakeholders or contractual dispute processes.

The following prompt template is designed to be pasted directly into your orchestration layer. It expects structured inputs from your drift detection pipeline and SLA registry. Replace every square-bracket placeholder with live data before invoking the model. The prompt enforces a strict JSON output contract suitable for automated ingestion by compliance dashboards, alerting systems, and audit archives.

textCopy
You are an Instruction Drift SLA Compliance Analyst. Your task is to produce a compliance report that maps detected instruction drift events to the SLA thresholds defined in the provided registry. You must identify breaches, calculate severity, and track remediation timelines.

## INPUTS

### DRIFT EVENTS
[DETECTED_DRIFT_EVENTS]

### SLA REGISTRY
[SLA_REGISTRY]

### REMEDIATION LOG
[REMEDIATION_LOG]

### SESSION CONTEXT
[SESSION_CONTEXT]

## OUTPUT SCHEMA

Return a single JSON object with the following structure:

{
  "report_id": "string",
  "generated_at": "ISO-8601 timestamp",
  "assessment_window": {
    "start": "ISO-8601 timestamp",
    "end": "ISO-8601 timestamp"
  },
  "sla_compliance_summary": {
    "total_drift_events": "integer",
    "breaches_detected": "integer",
    "overall_compliance_status": "COMPLIANT | BREACHED | AT_RISK"
  },
  "breaches": [
    {
      "breach_id": "string",
      "sla_threshold_ref": "string (reference to SLA registry entry)",
      "drift_event_refs": ["string (references to drift event IDs)"],
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "breach_description": "string (concise explanation of what threshold was violated and how)",
      "detected_at": "ISO-8601 timestamp",
      "remediation_status": "NOT_STARTED | IN_PROGRESS | RESOLVED | ESCALATED",
      "remediation_deadline": "ISO-8601 timestamp or null",
      "time_to_detect_minutes": "integer or null",
      "time_to_remediate_minutes": "integer or null"
    }
  ],
  "trend_analysis": {
    "drift_frequency_trend": "INCREASING | STABLE | DECREASING | INSUFFICIENT_DATA",
    "mean_time_to_detect_trend": "IMPROVING | STABLE | WORSENING | INSUFFICIENT_DATA",
    "mean_time_to_remediate_trend": "IMPROVING | STABLE | WORSENING | INSUFFICIENT_DATA",
    "sla_threshold_calibration_recommendations": [
      {
        "sla_threshold_ref": "string",
        "current_threshold": "string",
        "recommended_threshold": "string",
        "rationale": "string (data-driven justification based on observed drift patterns)"
      }
    ]
  },
  "unmapped_drift_events": [
    {
      "drift_event_id": "string",
      "reason_unmapped": "string (why no SLA threshold applies)"
    }
  ],
  "remediation_timeline": [
    {
      "timestamp": "ISO-8601 timestamp",
      "event": "string (detection, notification, remediation start, resolution, escalation)",
      "breach_ref": "string",
      "actor": "AUTOMATED | HUMAN | SYSTEM",
      "notes": "string"
    }
  ]
}

## CONSTRAINTS

1. Map every drift event in [DETECTED_DRIFT_EVENTS] to the SLA thresholds in [SLA_REGISTRY]. If a drift event does not correspond to any SLA threshold, list it in `unmapped_drift_events` with a clear reason.
2. A breach occurs when a drift event's measured severity, frequency, or duration exceeds the threshold defined in the SLA registry for the affected instruction layer.
3. Use the [REMEDIATION_LOG] to populate `remediation_status`, `time_to_detect_minutes`, `time_to_remediate_minutes`, and the `remediation_timeline`.
4. For `trend_analysis`, compare the current assessment window against the previous window if data is available. If insufficient historical data exists, set trend fields to `INSUFFICIENT_DATA`.
5. `sla_threshold_calibration_recommendations` must only be populated when observed drift patterns suggest a threshold is misaligned with operational reality (e.g., too sensitive causing false positives, or too lenient missing real degradation).
6. If [RISK_LEVEL] is `HIGH` or `CRITICAL`, flag the report for human review by setting a top-level field `"human_review_required": true` and include a `"review_priority": "IMMEDIATE | SCHEDULED"` field.
7. Do not fabricate drift events, SLA thresholds, or remediation actions. Work only from the provided inputs.
8. If any required input is missing or malformed, return a JSON object with `"error": "string"` and `"missing_fields": ["string"]` instead of the full report.

## RISK LEVEL
[RISK_LEVEL]

To adapt this template for your environment, wire the [DETECTED_DRIFT_EVENTS] placeholder to the output of your session-level or trace-level drift detection prompts. The [SLA_REGISTRY] should be populated from a configuration store or database that holds your team's agreed-upon thresholds for instruction fidelity, response latency under drift, and maximum allowable degradation per instruction layer. The [REMEDIATION_LOG] must be a structured log of actions taken after drift detection, including timestamps and outcomes. Set [RISK_LEVEL] based on the business criticality of the agent or session under review—this controls whether the report triggers mandatory human review. Before deploying, validate that the JSON output conforms to the schema using a JSON Schema validator in your pipeline, and log any schema violations as separate incidents. For high-risk domains, always route reports with human_review_required: true to an on-call SRE or compliance reviewer before the report is considered final.

This prompt is designed to run as a scheduled or event-driven evaluation job, not as a real-time interceptor. It expects a batch of session traces, the original instruction hierarchy, and the SLA threshold definitions as input. The output is a structured compliance report that downstream systems—alerting, dashboards, incident management—can consume. Because the prompt performs trend analysis and breach identification, it should be invoked on a regular cadence (e.g., hourly for high-volume agents, daily for lower-risk assistants) or triggered when a session exceeds a turn-count threshold that historically correlates with drift.

The implementation harness must enforce input validation before the prompt runs. The [SESSION_TRACES] input must be a list of objects, each containing a session identifier, a turn-by-turn log of model outputs, and the active instruction version at each turn. The [INSTRUCTION_HIERARCHY] must include the canonical system prompt, role definitions, tool-use policies, and output contracts with their version identifiers. The [SLA_THRESHOLDS] must define acceptable drift scores per instruction layer, maximum breach count per session, and the lookback window for trend analysis. Reject malformed inputs before model invocation and log the rejection reason. Use a structured output parser (e.g., a JSON schema validator) to confirm the model's response matches the expected compliance report schema before forwarding it to any downstream consumer.

Model choice matters here. Use a model with strong instruction-following and long-context reasoning capabilities (e.g., Claude 3.5 Sonnet, GPT-4o, or Gemini 1.5 Pro) because the prompt requires comparing many turns against a multi-layer instruction hierarchy. For high-throughput environments, consider a two-stage pipeline: a cheaper model performs initial per-turn adherence scoring, and this prompt synthesizes the scored traces into the SLA compliance report. Always log the raw prompt input, the model's raw output, and the parsed compliance report to an append-only audit store. This supports post-incident review and provides evidence for SLA disputes. If the report identifies a breach, the harness should automatically create an incident ticket with the breach details, affected session IDs, and the remediation timeline from the report. Do not auto-remediate drift based solely on this prompt's output—require human acknowledgment for any corrective action that alters production agent behavior.

Before deploying, calibrate the SLA thresholds using a golden dataset of sessions with known drift severity. Run the prompt against sessions where drift was confirmed by human review and sessions where no drift occurred. Tune the thresholds until the breach identification aligns with your operational tolerance for false positives and false negatives. After deployment, monitor the prompt's own performance: track the rate of unparseable outputs, the distribution of drift scores over time, and whether breach alerts correlate with user-reported quality issues. If the prompt's trend analysis recommends SLA threshold recalibration, route that recommendation to the team responsible for SLA governance rather than applying it automatically.