This prompt is designed for SRE, platform engineering, and operations teams who need to independently verify a specific SLA compliance claim against raw telemetry data. The core job-to-be-done is not continuous monitoring, but rather a targeted audit of a claim that has already been made—whether by a vendor, an internal service team, or an automated reporting system. The ideal user is an engineer or technical lead who has access to the underlying metrics database (e.g., Prometheus, Datadog, CloudWatch) and needs to confirm that a reported 99.95% uptime, a p99 latency of 200ms, or a remaining error budget of 80% is consistent with the raw data and the SLA's precise definitions.

Use this prompt when you have a specific, quantitative claim to verify and can provide the raw telemetry data, the exact SLA definition, and the measurement period. It is particularly valuable during incident postmortems to validate a vendor's root cause analysis, in quarterly reliability reviews to independently confirm internal reporting, and during contract renewal negotiations to audit a vendor's historical compliance. The prompt works by systematically checking three critical failure points: measurement window alignment (does the claim cover the correct time range?), exclusion rule application (were planned maintenance windows or specific error types correctly excluded per the SLA?), and metric definition consistency (is 'uptime' calculated from the load balancer, the application health check, or the synthetic probe?). The output is a structured compliance verdict with a clear pass/fail/determination and a detailed explanation of any discrepancies found.

Do not use this prompt as a replacement for a live monitoring dashboard or an alerting system. It is a point-in-time verification tool, not a real-time observability solution. It is also not suitable for generating an SLA report from scratch; it verifies an existing claim, it does not perform the initial calculation. The prompt requires the user to provide the raw data and the SLA text; it cannot query your metrics backend directly. If you cannot provide the raw data, or if the SLA definition is ambiguous and cannot be resolved, the prompt will return an 'Indeterminate' verdict rather than a guess. The next step after reading this section is to gather the three required inputs—the claim, the raw data, and the SLA text—and then proceed to the prompt template to begin the verification.

This prompt template is designed to be pasted directly into your AI workflow. It instructs the model to act as an SRE auditor, comparing a specific performance claim against a provided telemetry dataset. The prompt forces the model to check measurement windows, apply exclusion rules, and identify common gaming tactics before issuing a compliance verdict. Replace the square-bracket placeholders with your specific claim, raw telemetry data, and SLA definitions to make it operational.

markdownCopy
You are an SRE auditor. Your task is to verify a performance metric claim against provided telemetry data and produce a structured SLA compliance assessment.

# CLAIM TO VERIFY
[SLA_CLAIM_TEXT]

# TELEMETRY DATA (JSON)
```json
[TELEMETRY_DATA_JSON]

SLA DEFINITIONS & CONSTRAINTS

• Measurement Window: [MEASUREMENT_WINDOW]
• SLO Target: [SLO_TARGET_PERCENT]
• Exclusion Rules: [EXCLUSION_RULES]
• Metric Definition: [METRIC_DEFINITION]

VERIFICATION STEPS

1. Parse the telemetry data and identify the metric specified in the claim.
2. Filter the data to the exact measurement window defined in the SLA. Flag any data points outside this window.
3. Apply the exclusion rules precisely. Document which data points were excluded and why.
4. Calculate the actual performance metric over the valid, non-excluded data points.
5. Compare the calculated metric against the claimed metric and the SLO target.
6. Check for the following gaming patterns and flag any detected:
   • Window Shopping: Selecting a non-standard or overly narrow measurement window to improve results.
   • Exclusion Abuse: Applying exclusion rules too broadly or inventing new ones to remove unfavorable data.
   • Metric Mismatch: Using a different calculation method (e.g., average vs. median) than the SLA definition.
   • Data Sampling: Only providing a favorable subset of the full telemetry data.

OUTPUT SCHEMA

Return a single valid JSON object with the following structure. Do not include any text outside the JSON. { "claim_verified": boolean, "calculated_metric": number, "slo_compliant": boolean, "verification_details": { "data_points_total": number, "data_points_excluded": number, "exclusion_reasons": [string], "measurement_window_used": string, "window_anomalies": [string] }, "gaming_flags": [ { "type": string, "severity": "LOW" | "MEDIUM" | "HIGH", "description": string } ], "overall_assessment": string }

To adapt this template, start by replacing [SLA_CLAIM_TEXT] with the exact wording of the claim you are auditing, such as "Our service maintained 99.95% uptime for Q3." The [TELEMETRY_DATA_JSON] placeholder should be replaced with a structured JSON array of your monitoring data, including timestamps and metric values. Crucially, the [EXCLUSION_RULES] and [METRIC_DEFINITION] placeholders must be filled with the precise, unambiguous definitions from your SLA contract; vague rules here will lead to unreliable verification. For high-stakes compliance reporting, always route the final JSON output to a human for approval before it is published or used in a customer-facing report.

This prompt is designed to be a single step inside a larger SRE verification pipeline. It should not be exposed directly to end users or called without pre-processing. The harness is responsible for assembling the prompt's inputs from telemetry sources, enforcing the output schema, and deciding what happens after the model returns a result. The model's job is to reason about SLA compliance given structured data; the harness's job is to ensure that reasoning is grounded, reproducible, and safe to act on.

The implementation flow starts with data assembly. Before calling the model, the harness must query your observability platform (e.g., Datadog, Prometheus, Grafana) for the exact metric, measurement window, and exclusion rules specified in the SLA document. These values populate the [METRIC_DEFINITION], [MEASUREMENT_WINDOW], [TELEMETRY_DATA], and [EXCLUSION_RULES] placeholders. The [SLA_TARGET] should be pulled from a committed SLO definition, not from the model's memory. After the model returns its assessment, validate the output against a strict JSON schema that requires fields like compliance_status, measured_value, exclusion_events_applied, and assessment_confidence. Reject any response that is missing required fields or contains values outside expected enums (e.g., compliance_status must be one of compliant, non_compliant, or indeterminate).

Retry logic should be conservative. If validation fails, retry once with the same prompt and a stronger schema reminder appended. If the second attempt also fails, log the raw response and escalate to a human on-call channel with a pre-formatted summary. Do not retry more than twice for the same input. For high-severity SLA breaches (e.g., a customer-facing uptime SLO violation), always require human confirmation before sending an external status update or triggering an incident. The model's assessment_confidence field can be used as a routing signal: confidence below 0.85 should route to human review even if the output schema is valid. Log every invocation with the prompt version, model ID, input hash, output, and reviewer decision to build an audit trail for postmortems and prompt improvement.

Model choice matters here. Use a model with strong reasoning capabilities and reliable JSON mode (e.g., GPT-4o, Claude 3.5 Sonnet). Avoid smaller or older models that may hallucinate metric calculations or misapply exclusion rules. Set temperature to 0 to maximize determinism. If your SLA verification runs on a schedule (e.g., weekly compliance reporting), pre-compute the telemetry aggregates and cache the prompt inputs to avoid drift between runs. Do not pass raw log streams directly into the prompt; the harness should pre-aggregate and format the data into the structure expected by the [TELEMETRY_DATA] placeholder.

The most common production failure mode is metric definition gaming, where the measured value is technically correct but calculated over a window or with exclusions that misrepresent actual user experience. The prompt includes an eval step for this, but the harness should add a second layer of defense: compare the model's measured_value against a simple, independently calculated baseline (e.g., a raw Prometheus query for the same metric without exclusions). If the gap exceeds a configurable threshold, flag the result for review regardless of the model's compliance determination. This dual-check pattern catches cases where the model correctly applies the rules but the rules themselves are misleading.