Output Quality SLA Enforcement Prompt Template

This prompt is for SRE and platform teams who need to enforce quality SLAs in production AI systems. Use it when you have a model output that must be checked against defined quality thresholds before it reaches a downstream system or user. The prompt produces a structured SLA compliance assessment with violation details, impact severity, and remediation recommendations. It is designed for automated gating workflows where a binary pass/fail decision is not enough and you need an auditable record of why an output was accepted or rejected.

Do not use this prompt for initial schema validation or format repair. It assumes the output is already structurally valid and focuses on semantic quality dimensions such as accuracy, completeness, safety, and relevance. The ideal user is an engineering lead or platform operator who has already defined quality metrics and thresholds in an SLA document. The prompt requires you to provide the model output, the SLA criteria, and any relevant context such as the original user request or source documents. Without these inputs, the assessment will be unreliable.

Before deploying this prompt into an automated gating workflow, run it against a labeled test set of outputs with known violations. Measure whether the prompt correctly identifies SLA breaches and whether its severity ratings match your operational priorities. If the prompt is used to block outputs automatically, always log the full assessment for audit and set up monitoring on the block rate to catch threshold drift. For high-risk domains, route outputs with 'High' severity violations to a human review queue instead of blocking them outright.

This template is designed for SRE and platform teams who need to programmatically assess whether a model's output meets defined quality SLAs before it reaches downstream systems or users. It accepts the raw model output, the SLA definitions, and any relevant context, then produces a structured compliance assessment. The prompt is built to be wired into an automated gating harness where outputs that violate SLAs are blocked, flagged for review, or routed to remediation workflows.

codeCopy
SYSTEM: You are an SLA compliance auditor for production AI outputs. Your role is to evaluate model outputs against defined quality thresholds and produce structured violation reports. You must be precise, evidence-based, and conservative—when in doubt, flag potential violations for human review rather than passing borderline outputs.

INPUT:
- Model Output: [MODEL_OUTPUT]
- SLA Definitions: [SLA_DEFINITIONS]
- Context (optional): [CONTEXT]
- Previous Violation History (optional): [VIOLATION_HISTORY]

OUTPUT_SCHEMA:
{
  "compliance_status": "compliant" | "violation" | "review_required",
  "overall_score": <0.0-1.0>,
  "violations": [
    {
      "sla_rule_id": "<string>",
      "rule_description": "<string>",
      "severity": "critical" | "high" | "medium" | "low",
      "violation_detail": "<specific description of what failed>",
      "affected_output_segment": "<excerpt or reference>",
      "measured_value": "<actual value observed>",
      "threshold_value": "<required threshold>",
      "remediation_suggestion": "<actionable fix or escalation path>"
    }
  ],
  "impact_assessment": {
    "downstream_risk": "<description of what breaks if this output proceeds>",
    "user_impact": "<description of user-facing consequences>",
    "blast_radius": "<scope of affected systems or users>"
  },
  "recommended_action": "pass" | "block" | "quarantine" | "escalate",
  "escalation_target": "<team or queue> | null",
  "reviewer_notes": "<summary for human reviewer if escalated>"
}

CONSTRAINTS:
- Evaluate every SLA rule defined in [SLA_DEFINITIONS] against the model output.
- If any critical or high-severity violation is found, compliance_status must be "violation" and recommended_action must be "block" or "escalate".
- If only medium or low violations exist, compliance_status may be "review_required" with recommended_action "quarantine" or "escalate".
- Do not invent violations. Only flag issues you can point to in the output.
- If the output is truncated or incomplete, flag it as a violation with severity based on the SLA rules for completeness.
- For each violation, include the specific affected_output_segment as evidence.
- Impact_assessment must be concrete—describe actual downstream consequences, not generic warnings.
- If [VIOLATION_HISTORY] is provided, note any patterns or recurring violations.
- Do not modify the model output. Only assess it.

RISK_LEVEL: [RISK_LEVEL]

Adaptation guidance: Replace [SLA_DEFINITIONS] with your actual SLA rules structured as an array of objects containing rule_id, description, metric, threshold, severity, and measurement_method. For example, a factuality SLA might specify that all factual claims must be grounded in provided context with zero hallucinations. Replace [RISK_LEVEL] with high, medium, or low to adjust the conservatism of the assessment—higher risk levels should cause the model to flag borderline cases for review. The [VIOLATION_HISTORY] field is optional but valuable for detecting patterns like a specific model consistently failing the same SLA rule. When integrating this into a production harness, validate the JSON output against the schema before acting on the recommended_action field, and log every assessment for audit trails.

This prompt is designed to be called as a post-generation quality gate within a larger AI pipeline. It should receive the raw model output, the original input context, and the SLA definition as a structured object. The prompt is not a standalone chatbot interaction; it is a programmatic evaluation step that produces a machine-readable SLA compliance report. The calling application is responsible for providing the correct SLA schema, the output to be evaluated, and any relevant grounding evidence before invoking this prompt.

The implementation harness should enforce a strict contract around the prompt's input and output. Before calling the model, validate that the [SLA_DEFINITION] is a well-formed JSON object with required fields: metric_name, target_value, operator (e.g., gte, lte, eq), and unit. The [MODEL_OUTPUT] must be the exact string or structured object to evaluate. After receiving the model's response, parse the JSON output and validate it against the expected schema: { sla_compliant: boolean, violation_details: string | null, impact_severity: 'low' | 'medium' | 'high' | 'critical', remediation_recommended: string, confidence_score: number }. If parsing fails, retry the prompt once with a stronger format instruction. If it fails again, log the raw response and escalate to a human review queue. For high-severity violations (critical), the harness should automatically trigger an alert to the on-call channel and block the output from reaching downstream systems.

Logging and observability are critical for this workflow. Every invocation should log the SLA definition hash, the model output hash, the compliance result, the confidence score, and the model version used. This allows SRE teams to track SLA enforcement trends over time and detect drift in the evaluating model's behavior. Implement a periodic evaluation loop that runs this prompt against a golden dataset of known-compliant and known-violating outputs to verify that the SLA enforcement logic remains calibrated. If the false-positive or false-negative rate exceeds a defined threshold (e.g., 5%), the harness should automatically page the platform team and temporarily route all outputs to a manual review queue until the issue is resolved. Do not use this prompt as the sole enforcement mechanism for regulatory or safety-critical SLAs without a human-in-the-loop override.