Stakeholder Feedback Loops & SLA Alignment.

A Claude-based system's "SLA" is not one number - an architect has to align stakeholders on separate concepts that traditional software conflates: on the infrastructure side alone there are three different things (observed historical uptime, a service tier's stated target, and an actual contractual SLA), and none of the first two is the third. Layered on top is a wholly separate dimension, output-quality reliability (is the answer good enough). These fail independently: a nondeterministic system can be fully "up" while producing unacceptable output, so no infra number, observed or targeted, can stand in for output quality, and neither can stand in for a real contractual commitment either.

Anthropic publishes real, checkable infrastructure-level data an architect can start a negotiation from - live observed uptime at status.claude.com and three named API service tiers, one of which states an uptime target. Neither of those is a contractual SLA: a genuine contractual SLA, the number an enterprise customer can actually hold Anthropic to with remedies if missed, has to be separately negotiated into the customer's own agreement and is not published as a percentage anywhere. The output-quality half has no vendor number at all: it is negotiated project-by-project against the project's own eval results, and this is the half most often left implicit when a team reuses a generic "SLA template."

Start from a real, checkable OBSERVED baseline - and treat it as a retrospective record, not a promise. Anthropic publishes live, historical uptime for each product surface at status.claude.com - at time of writing, 99.57% API uptime and 99.51% Claude Code uptime over a trailing 90-day window. This describes what already happened; the status page makes no claim it will hold going forward, and the number moves. Citing it AS the SLA is a category error - it's a data point for a negotiation, not the contract itself.

A service tier's published number is a TARGET, not a contractual guarantee - and it is a different thing again from an observed uptime figure. Standard is the default tier with best-effort availability, no percentage attached at all. Priority Tier, available only to organizations with an existing capacity commitment, "targets 99.5% uptime with prioritized computational resources" per Anthropic's own service-tier docs - "targets" is doing real work there: it's a stated operating goal tied to a paid capacity commitment, not a penalty-bearing SLA guarantee. As of current docs, new Priority Tier capacity commitments are no longer available for purchase for new customers; existing commitments continue through their contract end date, and new guaranteed-capacity needs route through direct sales rather than self-serve tier selection. Batch is async, has no latency SLA, and costs less.

A CONTRACTUAL SLA is a third, distinct thing from either number above, and Anthropic does not publish one as a percentage. Both the observed 90-day uptime and a service tier's target describe Anthropic's own operating characteristics; neither is, by itself, a legally binding commitment with remedies (service credits, termination rights) if missed. A real contractual SLA has to be separately negotiated into the customer's own agreement, typically through direct sales/legal - it is not something to infer from the status page or the service-tier docs. Citing the observed figure or the Priority Tier target as if it were the signed contractual SLA confuses a historical record and an aspirational target with a legal commitment.

The output-quality SLA has no vendor-published number at all - it is project-derived. Accuracy thresholds, hallucination-rate ceilings, and the confidence band that triggers escalation to a human all have to come from the project's own eval suite and get negotiated with the stakeholder as a project-specific bar. This is the part most often skipped when a team reaches for a generic SLA template that only covers uptime.

A feedback loop keeps all of these visible as real traffic shifts. Recurring eval-score reviews with the stakeholder, not a one-time launch gate, are what catch an output-quality bar quietly slipping after usage patterns change; observed uptime is monitored continuously by definition (status dashboards), but a customer's actual contractual terms and the quality bar both need that same discipline built in deliberately, not assumed from a public status page.