SLA/SLO Definition

Service level expectations exist only as vague promises — 'we aim for high availability' and 'the platform should be fast.' There are no written SLAs, no defined SLOs, no error budgets, and no measurement methodology. When a customer complains about downtime, the response is 'we'll look into it' because there is no defined target to measure against. Reliability is a feeling, not a metric.

None — AI cannot monitor compliance or predict SLO breaches because no SLA/SLO definitions exist in any system.

Some SLOs exist as scattered documentation — a slide deck from the last board meeting mentions '99.9% uptime,' a customer contract has vague availability language, and an engineer wrote target latencies in a README. But there is no single source of truth for what the targets actually are, how they are measured, or what happens when they are breached. 'What's our SLA for the API?' gets different answers from sales, engineering, and support.

AI could parse individual documents for SLO mentions, but cannot assemble a coherent reliability target framework because definitions are inconsistent, scattered, and often contradictory across sources.

SLA/SLO definitions live in a dedicated registry with consistent fields — metric name, target, measurement window, owning service, and responsible team. Engineers can look up the SLO for any service. But the definitions are disconnected from actual measurement — the SLO says '99.95% availability' but there is no link to how availability is calculated, which monitoring system measures it, or what the current error budget consumption looks like.

AI can read SLO definitions and identify services with missing targets, but cannot assess compliance or predict breaches because definitions are not linked to their measurement infrastructure.

SLA/SLO definitions are comprehensive records linked to their measurement infrastructure. Each SLO connects to the specific Prometheus query or Datadog monitor that measures compliance. Error budget burn rates are calculated in real-time. An operator can query 'show me all SLOs with less than 20% remaining error budget this month, the services they cover, and the incidents that consumed budget' and get an accurate, current answer.

AI can monitor SLO compliance in real-time, predict error budget exhaustion, and correlate SLO impact with incidents and deployments. Cannot yet autonomously adjust targets because SLO-setting involves business trade-offs between reliability investment and feature velocity.

SLA/SLO definitions are formal policy entities in a reliability ontology. Each definition has typed relationships to the services it governs, the contractual obligations it fulfills, the measurement system that evaluates it, and the error budget policy that constrains operational decisions. An AI agent can ask 'generate an error budget-aware deployment policy for Q2 that prevents releases to services within 10% of their SLO breach threshold' and produce a valid, constraint-satisfying policy.

AI can autonomously enforce error budget policies, generate deployment gates based on SLO health, and recommend target adjustments based on historical reliability patterns. Human judgment is needed for contractual SLA commitments and business-level reliability trade-offs.

SLA/SLO definitions are self-maintaining reliability policies. When a service's architecture changes, its SLO measurement adapts automatically. New services inherit appropriate SLO templates based on their tier and domain. Error budget policies evolve from incident pattern analysis and deployment impact history. The reliability framework generates its own operational rules from platform behavior rather than relying on manual policy definition.

Can autonomously maintain, measure, and evolve the complete SLA/SLO framework in real-time, adapting reliability targets and enforcement policies to platform changes without human policy administration.

Ceiling of the CMC framework for this dimension.