SLOs for Software That's Allowed to Be Wrong: Reliability Targets for AI

A reliability target for an AI feature needs two numbers, not one: an availability SLO like classic SRE practice, plus a quality SLI—typically a pass rate against a rubric—with its own SLO and error budget. Uptime alone can't catch a model that responds instantly with a wrong or unsafe answer.

Quick Answer: Set an SLO for AI products by pairing your existing uptime target with a quality SLI (percent of responses passing a graded rubric), then spend the resulting error budget deliberately—burn it fast on low-risk experiments, conserve it before a risky prompt or model change ships.

Why uptime SLOs go blind on AI features

A 99.9% uptime SLO answers "did the service respond," not "was the response any good." For deterministic software those questions mostly collapse into one—a 200 response is usually a correct one. For probabilistic systems they diverge completely, and that gap is where user trust quietly erodes.

An LLM-backed feature can return a 200 in 400 milliseconds and still hallucinate a policy, misread the user's intent, or produce an unsafe recommendation. Your existing dashboards report a healthy system throughout. This is the core failure mode described in the complete guide to LLMOps observability: traditional infrastructure monitoring instruments the pipe, not the water flowing through it.

Site Reliability Engineering, as codified in Google's SRE book, defines an SLI (service level indicator) as a measurement, an SLO (objective) as the target for that measurement, and an error budget as the allowed slack between 100% and your SLO. Nothing in that model requires the SLI to be about latency or uptime—it requires the SLI to be a well-defined, user-relevant measurement. Quality qualifies.

The uptime/quality gap in practice

Three of these five rows show a healthy uptime dashboard alongside a degraded user experience. That's the gap a quality SLI exists to close—without it, a platform PM is flying on one instrument in a two-instrument cockpit.

Choosing a quality SLI: pass rate against a rubric

A quality SLI should be the percentage of responses that pass a defined rubric, scored consistently across a representative sample of production traffic. This turns "is the AI good" from a vibe into a number you can put an objective and a budget against, the same way p99 latency turns "is the site fast" into one.

What makes a rubric usable as an SLI

1. Binary or ordinal scoring per criterion—pass/fail or a 1-5 scale, not free-text judgment, so results aggregate.
2. Stable criteria over time—if the rubric changes every sprint, the SLI trend is meaningless; version it like an API.
3. Traceable to a real failure mode—each criterion should map to something a user or support ticket actually complained about.
4. Scored on a sample, not everything—100% grading coverage is rarely necessary or affordable; a representative, stratified sample is.
5. Graded by more than one method—automated checks (format, groundedness, refusal correctness) plus periodic human or LLM-judge review for nuance.

A rubric commonly blends several sub-checks: factual groundedness (does the answer match retrieved source material), format compliance (did it return the schema the downstream code expects), tone/safety (did it avoid a disallowed claim), and task completion (did it actually do the thing the user asked). Each sub-check can have its own pass rate, and the composite becomes your quality SLI.

This is exactly the measurement gap Prodinja's Evals concept is built to close—it walks you through defining rubric criteria against representative prompts and reading back a pass rate you can quote as a number, rather than eyeballing a handful of transcripts and hoping they're representative.

Picking an achievable target, not an aspirational one

Resist the instinct to set the quality SLO at 99%+ just because that's the uptime convention. Google's own SRE guidance is explicit that 100% is rarely the right target for any SLI—it's usually the wrong amount of reliability to pay for, since the cost of the last few points always grows faster than the value they add. For a generative feature, a 100% quality target is not just expensive; for genuinely open-ended tasks it may be unreachable at any cost, because the acceptable-answer space is inherently fuzzy.

A more workable starting point: baseline your current pass rate honestly (run the rubric against a week of recent traffic before promising anything), then set the SLO a few points above baseline with a review date, rather than picking a round number out of the air.

Building the error budget and spending it deliberately

An error budget is simply 100% − SLO, expressed as a count of allowed failures over a window—the same arithmetic Google's SRE model uses for availability, applied to quality instead. If your quality SLO is 92% over a rolling 30-day window and you serve 50,000 graded interactions in that window, your budget is 4,000 failing responses.

A worked example

With 3,100 of budget left, a platform PM has room to greenlight a moderately risky next change—a new retrieval source, a temperature bump, a model swap—and watch the burn rate. If a change consumes 2,000 of the remaining 3,100 in three days, that's a burn-rate alarm exactly like a latency SLO's, and it should trigger the same response: pause the rollout, roll back, or throttle exposure.

The governing rule that makes this useful: the error budget, not a gut feeling, decides how aggressively you can ship. Budget healthy → ship the experimental prompt variant to more traffic. Budget nearly exhausted → freeze non-essential changes and spend the remaining sprint on regressions, not new capability. This is the same discipline the three-dashboards framing for AI products day one recommends: pick your monitoring layers before an incident forces the conversation.

Governing risky prompt changes with the budget

1. Before shipping, estimate the change's blast radius—what fraction of traffic sees the new prompt/model/retrieval path initially.
2. Gate the rollout on remaining budget: a large remaining budget permits a wider initial exposure; a thin one caps it to a canary slice.
3. Grade continuously during rollout, not just before—drift after launch is common and easy to miss without ongoing scoring, as covered in why quality drift shows up with no stack trace.
4. Set a burn-rate alert, e.g. "more than 25% of the remaining budget consumed in 24 hours," mirroring standard SRE burn-rate alerting math.
5. Roll back on breach, and treat every failure the rubric catches as a candidate eval case, closing the loop described in turning production failures into eval cases.

Operationalizing the SLO: cadence, ownership, and review

A quality SLO only works if someone owns the number and a cadence exists to revisit it—an SLO nobody reviews decays into a number on a slide nobody trusts. Treat it with the same operational rigor as an availability SLO: a named owner, a standing review, and a documented process for what happens on breach.

Who should own what

Keep the review conversation grounded in actual user impact, not abstract accuracy. A useful discipline borrowed from customer-facing product work: map quality failures back to the specific jobs users are hiring the feature to do, the way the JTBD framework insists you tie any metric to a real outcome the customer cares about, not just an internal proxy. A rubric criterion that never traces to a user complaint or a lost task is a candidate to retire.

Common mistakes to avoid

• Grading only golden-path prompts. A rubric scored solely against easy, well-formed inputs overstates real-world pass rate; sample real traffic, edge cases included.
• Letting the rubric silently drift. Adding or loosening criteria without versioning breaks the ability to trend the SLI over time.
• Treating the error budget as a punishment. Its purpose is to make risk-taking legible and boundable, not to freeze shipping—Google's SRE book frames the budget explicitly as a tool for balancing innovation velocity against reliability, not a brake pedal alone.
• Skipping the human review layer entirely. Automated checks catch format and groundedness well; tone, nuance, and edge-case harm often still need a human or LLM-judge pass on a sample.
• Ignoring where in the journey the failure lands. A quality miss at a first-time-use moment costs more trust than the same miss deep in an expert workflow—weighting matters, echoing how mapping the customer journey's emotional highs and lows changes which failures deserve urgent attention.

Key Takeaways

• Uptime SLOs measure whether the system responded, not whether the response was good—AI features need a second, quality-specific SLI to close that gap.
• A quality SLI is best expressed as a pass rate against a versioned rubric, scored on a representative sample of production traffic, not just easy golden-path prompts.
• Set the quality SLO from an honest baseline, a few points above current performance, rather than defaulting to a 99%+ target borrowed from uptime conventions.
• The error budget (100% minus the SLO) turns "can we ship this risky prompt change" into arithmetic—a remaining-budget check rather than a debate.
• Burn-rate alerts on the quality budget catch regressions early, the same way latency burn-rate alerts do for availability SLOs.
• Ownership and cadence matter as much as the number itself—an SLO nobody reviews quarterly, and a budget nobody watches in real time, stops functioning as a control.
• Prodinja's Evals concept is designed to generate exactly this raw material—rubric-based pass rates you can turn directly into a quality SLI.