AI Reliability Engineering: SLOs for Model-Backed Features

What Is AI Reliability Engineering?

The 2025 DORA State of AI-assisted Software Development report found that higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability. DORA states that directionally, with no figure attached, and calls it an association with no causal claim. The same report found 90% of respondents using AI at work and more than 80% believing it has increased their productivity.

In a March 2026 post on its own site, DORA frames the pattern as amplification. “AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.”

• Where the platform is strong - DORA describes AI acting as a powerful collaborator for teams that already have a high-quality internal platform, strong APIs, clear workflows and strong testing practices.
• Where it is weak - with fragmented tooling, siloed data or fragile infrastructure, DORA says AI “will simply help them generate technical debt faster.”

Read one way, instability is a failure rate measured over a window, which is the quantity an error budget was built to track. That reading is my own, and DORA does not connect its instability finding to error budgets for model-backed features.

AI reliability engineering is the practice of running a model-backed feature against a stated objective, a measured indicator and an agreed failure allowance, the way site reliability engineering runs a service. The classical form of that discipline is covered in our guide to performance engineering.

• The boundary with neighboring work - evaluation sits upstream of this and observability sits underneath it, and neither one sets the threshold you are agreeing to.
• A stated objective - written down, agreed with whoever owns that product surface, and expressed in terms a user of it would recognize.
• An indicator from live traffic - a count of real requests, each classified good or bad by a predicate you own and can defend in a review, and the predicate has to hold when the same input returns a different output on a shared endpoint.
• An allowance both sides signed - the share of requests permitted to fail over the window before release work yields to reliability work.
• A reason the allowance is above zero - in that same March 2026 post DORA calls the drive for rapid output “one of many factors that can stand in opposition to the long-term health of the codebase,” writing that “we are offloading a lot of development work to non-deterministic tools that are not fully adequate yet at producing fully trustworthy and high quality outputs.”
• A separate finding on trust - DORA cites the 2025 report’s result that 30% of developers report little or no trust in AI-generated code, attributing that distrust to AI tools being “incapable of signaling uncertainty and output hallucinations with high confidence.”
• An owner for the day it runs out - Google’s SRE Workbook says that to use an error budget “you need a policy outlining what to do when your service runs out of budget,” and it is writing about conventional services, so carrying that policy across to a model-backed feature is my call.

Defining the SLI for a Model-Backed Feature

Google’s SRE book gives the definition you already work from: an SLI is “a service level indicator”, and then, in the book’s own words, “a carefully defined quantitative measure of some aspect of the level of service that is provided”.

• The shape Google prefers - the SRE Workbook recommends treating the SLI as “the ratio of two numbers: the number of good events divided by the total number of events.”
• The carve-out - the Workbook states that as a recommendation and leaves room for indicators that do not fit the form.
• What the ratio asks for - a predicate that sorts each event into good or bad, and nothing else. The Workbook’s definition attaches no determinism requirement to that predicate, and the step I take from there is my own.

So a feature whose output differs from one run to the next stays eligible for an SLI. What it lacks is an agreed predicate, and that agreement is a product decision.

Thinking Machines Lab frames the caller’s side of this as a matter of perspective. The inference server can be described as deterministic, while from one caller’s view the other concurrent users are “a nondeterministic property of the system”. The mechanism they name sits in kernels that are not batch-invariant meeting server load that varies, so the quote describes what a caller can see.

Carry two indicators for the feature, computed by different machinery:

• The infrastructure SLI - unchanged from what you run today: availability, latency and error rate on the model call itself, emitted by the service that makes the call.
• The behavioral SLI - new: whether the response cleared a stated bar, judged by a grader against a sample of real traffic.
• Coverage - the infrastructure indicator is computed on every request and costs a counter increment. The behavioral one is computed on a sample, because grading every response means a second inference call for every first one.
• Sampling rate - the rate you pick sets the width of the interval around your quality number and the smallest regression you can detect in a window. Choose it against the decision you want to make, then write it into the SLO definition.
• Gaming - the arXiv preprint “Revisiting Service Level Objectives and System Level Metrics in Large Language Model Serving” (arXiv:2410.14257, October 2024, revised October 2025) observes that manually delaying token delivery to the time-between-tokens deadline improves SLO attainment while the user’s experience gets strictly worse. That paper never uses the term SLI, so carrying the warning across to your indicators is my own step. Read both indicators before a release gate passes.

The predicate is now a component of the system you are measuring. If the grader is itself a model, it carries the same run-to-run variance as the feature, and your SLI inherits it.

• Version the predicate with the objective - a target means nothing without the grader version and sampling rate it was measured against. Write both into the SLO definition beside the target number, so the number can be reproduced later.
• Treat a grader change as an instrument change - prompt edits, model version bumps and sampling parameter changes all move the bar. Re-measure after any of them before you read a move in the quality number as a feature regression.

Writing an Error Budget Policy for AI Features

The SRE Workbook pairs the number with an obligation: “you need a policy outlining what to do when your service runs out of budget.” For an SLI shaped as good events over total events, the Workbook states the “error budget is 100% minus the SLO,” measured over a window you name. Pick 97% as an illustrative acceptable-answer target over four weeks and the budget is the remaining 3%, agreed in advance.

Teams skip that agreement once a model sits in the path. The SRE book settles the target question first: “100% is probably never the right reliability target.” An error budget already prices in a share of failed events, so a feature whose output varies between identical calls fits the same arithmetic.

Neither Google chapter is talking about models, and the error-budget material addresses conventional services. Carrying it over to a feature with an LLM in the path is my extension, and so is the acceptable-answer predicate.

Name what freezes when the budget is gone, using the vocabulary of your feature.

• Prompt changes - system prompt edits, few-shot swaps and instruction rewrites freeze on the same terms as application code.
• Model version upgrades - no move to a newer checkpoint while the budget is exhausted, including the vendor’s default.
• New tool integrations - no extra function, retrieval source or downstream call joins the loop until the burn is repaid.
• Expansion to new user segments - the feature holds its current cohort, locale and plan tier until the budget refills.
• What keeps shipping - changes whose only job is repaying the burn stay unfrozen: a rollback, a guardrail, a stricter refusal threshold, a cheaper fallback.

Alerting keys on burn rate measured over a window.

• Burn rate as the page trigger - the page fires on the rate of spend, since a rate far above the feature’s designed rate marks a regression.
• Pager meaning - a probabilistic feature emits bad outputs at its designed rate daily, so paging per case teaches responders to clear alerts unread.
• Fast and slow windows - a fast window catches outages and serving regressions, a slow one catches quality decay that trips no latency alarm.

Ownership gets contested the first time burn traces back to the provider.

• The budget belongs to the composite feature - prompt, retrieval, tool calls, parsing, fallback and vendor call measured together at the user-visible outcome.
• The vendor holds a contract - the SRE book calls SLA consequences “most easily recognized when they are financial,” a rebate or a penalty, while the answers your users missed stay on your budget.
• One named owner - the team shipping the feature spends and defends the budget, since it picks the model, prompt and fallback.

Provider-side change accounts for weeks when nobody on the team shipped anything.

• Unattributed burn still counts - a provider-side serving change or a deprecated checkpoint spends budget like a bad prompt, and the freeze applies identically.
• Pre-agreed remedies - name the moves allowed without a meeting: pin a prior model version, route to the non-model path, or accept the burn with a written expiry.
• Evidence you already hold - your logged inputs, outputs and judgements turn “the model changed” into a support case a vendor can act on.
• A review trigger - repeated provider-caused burn argues for a lower SLO or a second provider, and the policy names who decides.

Reliability of the Model-Serving Dependency

The model provider sits inside your request path, and you cannot patch it, roll it back, or read its logs. The surrounding controls are covered in deterministic infrastructure for AI agents. Your dependency playbook assumes a service that fails loudly and identically for every caller, which a model endpoint often does not. Each failure mode needs a test that provokes it and a control that bounds its cost in production.

• Provider outage - the call errors, or hangs open until your own timeout fires. Inject both shapes at the client boundary, errors and stalls separately, because a hang consumes a connection slot that an error does not. The control is a product-approved answer for “no model available” that ships with the feature, plus an availability SLI counting a degraded response as a model-path failure at HTTP 200.
• Rate limiting and quota exhaustion - these are load-dependent, so they arrive during your busiest minute and hit only part of the traffic. Drive synthetic load past your provisioned ceiling on a non-production key and record which requests get shed first. Control it with headroom as a first-class signal, tracked separately from error rate, plus a shedding priority that drops low-value traffic before a paying user’s request.
• Fallback model cascades - a fallback is a different system with different behavior, so failing over restores availability without restoring your behavioral SLI. Run the same acceptance checks on every model in the cascade and keep the pass rate per model, since a blended number moves only as far as the fallback’s share allows. The control is attribution: tag every response with the model that served it, then track behavioral budget burn per model.
• Fallback share as its own threshold - availability can sit at target while most traffic runs on the second choice and no error budget is spent. Alert on the fallback’s share of requests crossing a set percentage over a rolling window, independent of error rate. Set that window to an hour so a brief retry storm does not trip it while a sustained shift does.
• Unverified model identity - the identifier you sent records what you asked for, and confirming what actually served the call takes a separate check. Assert on every call that whatever identity the response exposes matches your request, and treat a mismatch as a deploy event, paged like your own release. Where the provider exposes no served-model identity, log that gap and carry whatever identity you do have on your behavioral SLIs, so a quality shift bisects against a provider-side change.
• Shared serving - the endpoint is shared infrastructure, so identical inputs can return different outputs depending on conditions inside it you do not see or control. Replay one fixed input set at several times of day and measure the spread across those runs. Set your SLI threshold from that observed distribution, because a predicate calibrated on one golden run will fire on ordinary variation.

The provider’s published numbers are measured at their serving boundary, which sits behind yours. Wang and colleagues, in “Revisiting Service Level Objectives and System Level Metrics in Large Language Model Serving” (arXiv:2410.14257, posted 2024, revised 2025), argue that the metrics used in LLM serving are gameable: manually delaying token delivery to the time-between-tokens deadline improves per-request SLO attainment while making the user’s experience strictly worse. Measure at your own client boundary, and keep the provider dashboard as a second input on the incident timeline.

Degraded States for an AI Feature

A model-backed feature can return 200, in the right shape, inside the deadline, and still fail the person asking. Write those in-between states down as product outcomes, in the words a support ticket uses, before an incident names them for you at 2am.

• Answered by a weaker model - the primary endpoint timed out or rate limited, and the fallback served the request. The response shape and latency profile match the primary path, and nothing in the payload marks the downgrade.
• Answered without retrieval - the index or the document service was unreachable, so the model answered from parameters alone. The output stays fluent, and the retrieved passages it normally cites are absent. An ungrounded answer that reads confident is the one most likely to be accepted and acted on.
• Declined to answer - a filter, a low confidence score or a policy check blocked the response. This is the safe state. The user leaves without the thing they came for, on a request your infrastructure counts as served.
• Answered slowly - a retry, a second sampling pass or a verification step fired underneath. The answer is correct, the wall-clock time roughly doubled, and every per-attempt log line looks normal in isolation.

A refusal and a wrong answer both spend budget, and neither increments an error counter, so a dashboard built on status codes reports a healthy week while a growing share of users are turned away.

I have watched a feature’s success rate sit flat while its refusal rate climbed, because refusals were logged as completed requests.

Metric gaming happens inside the serving stack too, on different vectors. Wang et al., in their LLM serving preprint (arXiv:2410.14257), report that delaying token delivery to the time-between-tokens deadline improves per-request SLO attainment while the experience gets worse, and that abandoning requests already past their SLOs raises system level metrics such as goodput.

• Enumerate the acceptable degraded states - decide in advance which ones ship to users and which ones page someone. Fallback model allowed, retrieval bypass allowed only with a visible notice on the response, silent retrieval bypass treated as an incident.
• Emit an outcome field on every request - answered_primary, answered_fallback, answered_ungrounded, refused, answered_after_retry. Latency and status stay where they are, and the outcome field becomes what the SLI reads.
• Give refusals their own ceiling - a refusal rate target held separately from error rate, so the safe state draws down a budget of its own. Set the first target from the measured refusal rate of the past month plus headroom, so the ceiling bounds growth from the day it ships.
• Alert when the outcome mix moves - the ratio between those outcomes shifting is usually the earliest signal available, arriving days before the first quality complaint reaches support. A volume threshold on the same data fires later, once the shift is large enough to move the total.
• Publish the degraded contract - tell product and support which states are normal operation, so a fallback answer is on the list support already has in hand when a customer calls.

The SRE Workbook recommendation to treat an SLI as “the ratio of two numbers: the number of good events divided by the total number of events” survives intact. What changes is who defines good, and how many ways a request can be not-good while returning 200. The refusal ceilings and outcome budgets above are my extension, and Google claims none of them.

Fault Injection for Model-Backed Systems

Your existing game days stop at the service boundary. The model path adds boundaries they never reach: the provider call, the retrieval call, and the tool call, each with a user-visible failure mode you can only characterise by watching it happen under production load.

Inject at the client wrapper you already own, the layer that holds your timeouts and retries, so the fault lands on the same code path a real provider incident would hit. Run each of these against a canary cohort with your behavioural SLI still recording.

• Provider latency injection - Add a fixed delay in front of the provider call, first just under your timeout and then well past it. This proves the timeout actually fires at the value in your config and that the wait state the user sees is the one you designed. Streaming features fail differently here, because the first token arrives, the stream stalls mid-answer, and a client that only watches for connection errors will show a truncated response as if it were complete.
• Forced provider errors and rate limits - Return 429 and 5xx responses at a rate you control instead of waiting for the provider to do it for you. This proves the fallback path executes before a retry storm turns a provider blip into a self-inflicted outage. Check that your retry honours the Retry-After header and that the fallback triggers on the error classes you assumed it would.
• Forcing the fallback model to serve - Pin a canary cohort to the fallback model for a full measurement window, with no primary in the path at all. If quality is measured on the primary, and the fallback was signed off once at integration time, then it serves real traffic during every provider incident with nobody recording what it returned. Running a cohort on it is the only way to get your behavioural SLI measured on the state you degrade into, and the only way to catch a fallback that holds your latency target while missing your correctness target.
• Retrieval faults - Return empty result sets, a deliberately stale index snapshot, and documents pulled from a neighbouring corpus that looks plausible but answers a different question. This proves whether the feature admits it does not know, or whether it writes a confident answer over an empty context window.
• Tool and function-call timeouts - For agentic features, hang one tool endpoint past the per-call budget and leave the rest healthy. This proves whether the agent surfaces the failure, loops into the same wall until the step budget runs out, or reports the task finished with the tool result silently missing.

Record the same SLIs during the injection run that you record in steady state, and set the fallback numbers as their own target. A feature that spends a meaningful share of its error budget in fallback is running to whatever quality bar the fallback happens to clear.

Every one of these faults lands on code you own. None of them makes the model itself behave predictably, and the same input against a shared inference endpoint can still return a different answer for reasons that have nothing to do with your request.

Incident Response When the Model Misbehaves

A behavioural failure returns 200 OK with a plausible body, so an error-rate count says nothing about what those responses did downstream. What to instrument beforehand is covered in AI observability. Grade severity by what the wrong output caused.

• Sev1 - it moved money, wrote to a record, reached a customer, or fed a downstream agent with no human between.
• Sev2 - it reached a person who could have acted on it, with review the only barrier to effect.
• Sev3 - wrong in a way the user could see, so they discarded it and retried.
• Sev4 - the grader caught it, the fallback fired, and the user got a degraded but honest response.

Page on a single Sev1; an error-rate threshold computed over a window will not fire on one request. Before anyone argues about cause, pull up the failing request itself, which logs of request id, latency and status cannot reconstruct.

• Prompt and template version - the rendered prompt as sent, plus the template identifier.
• The model identifier returned - the one in the response body, which can differ from the alias you sent.
• Retrieval results - document ids, chunk ids, scores, and the index version.
• Tool calls and arguments - every call in order, the arguments the model chose, and what came back.
• Grader verdict and version - the predicate’s decision, its stated reason, and the version that issued it.

“Roll back” assumes one artifact with a previous version. In a model-backed path the thing that changed can sit in several places, and some never passed through your deploy pipeline.

• A prompt or template edit - shipped through a config path that nobody reviews like code.
• A provider-side model update - served behind the alias you pinned months ago, repointed with no deploy on your side.
• An index rebuild - same query, different neighbours, different grounding.
• A grader change - reclassifying behaviour you were already shipping.
• Nothing you own - identical inputs on a shared endpoint can return different outputs, so the diff you want may not exist.

In METR’s randomized controlled trial, 16 experienced open-source maintainers worked 246 real issues in their own mature repositories on early-2025 tooling, and allowing AI made those tasks take 19% longer. Afterwards those same developers estimated AI had sped them up by 20%.

Discount a first responder’s severity estimate the same way, and re-grade against the captured run before paging. METR has since published a follow-up it describes as an unreliable signal, so treat that trial as a snapshot of early-2025 tooling rather than a current measurement.

• The interval - METR restated the 19% in February 2026 with a confidence interval of +2% to +39%.
• A follow-up METR disavows - it calls the newer raw data “an unreliable signal of the current productivity effect of AI tools”, biased downwards by selection effects.
• METR’s own reading - developers are probably more sped up in early 2026 than its early-2025 estimates indicated, on “only very weak evidence for the size of this increase”.

Close the postmortem by changing the evaluation surface itself.

• A new case in the suite - lifted from the failing run, with the expected verdict beside it.
• A change to the predicate - the grader passed something a user would reject, so the grader is the defect.
• A tighter fallback - a lower confidence threshold or a human gate on the path that carried it.
• An owner for whatever moved - usually the prompt template, so the next edit leaves a reviewable trail.

Conclusion

Start with the predicate rather than the objective. Until somebody writes down what makes a response acceptable, the number you pick for an SLO is decoration, because nothing can compute whether you met it.

Then write the policy before you need it. The value of an error budget is that the argument about whether to keep shipping happens on a quiet afternoon rather than during an incident with the feature already degraded.

Measure the states you fall back into, since those are the ones nobody instruments and the ones your users are most likely to meet on a bad day.