Between August and early September 2025 three separate infrastructure bugs degraded Claude's output quality - one affected 16% of Sonnet 4 requests in the worst hour of 31 August - while error rates and latency stayed normal. What class of failure is this, and what would you have had to build beforehand to notice it?

The trigger

Anthropic's published postmortem describes three overlapping causes: a context-window routing error, an output corruption traced to a misconfiguration on the API's TPU servers, and a latent miscompilation in the approximate top-k path of the XLA:TPU compiler that affected Haiku 3.5 for nearly two weeks. None of them produced an error. Requests returned 200, within latency budget, with well-formed responses that were worse.

Why detection lagged

Three mechanisms compound here, and they are not specific to model serving.

• There was no correctness oracle. For a request-serving system you can assert that a response parses, that a total sums, that a row exists. For generated output there is no cheap assertion that distinguishes a good answer from a mediocre one, so the only available signal is statistical, over a population, against a baseline.
• The signal was diluted. A bug touching 16% of one model's requests at its peak is invisible in an aggregate quality average, and invisible in a dashboard that reports per-endpoint error rate. You detect a 16% subpopulation only if you are already slicing by the dimension that separates it — here the serving platform and the routing decision, which nobody had a reason to slice by until afterwards.
• The evidence was out of reach. Anthropic states that its own privacy and security controls limited engineers' access to user interactions, so the reports could not be reproduced from the traffic that produced them. A control that is correct in every other respect removed the fastest diagnostic path.

What would have caught it

• A continuously scored golden set — a fixed, held-out population of requests replayed against production on a schedule, scored automatically, tracked as a time series per model and per serving platform. This is the correctness oracle you could not get per-request, bought by sampling instead.
• Slicing by infrastructure dimensions, not only product ones. Quality by accelerator type, by region, by deployment version, by routing decision. The bug lived in a dimension the product dashboards did not have.
• A privacy-preserving reproduction path built in advance: consented debug traffic, synthetic replays that mirror real shapes, or a break-glass procedure with audit. Deciding this during an incident costs days.
• Treating user reports as a leading indicator with a threshold. Qualitative complaints arrived before the metrics moved. They usually do.

When this is the wrong answer

Golden-set scoring costs real money and real engineering, and it is a poor investment for a system that does have a cheap correctness oracle. If your service can assert its own output — a checksum, a schema, a reconciliation, a total that must balance — build the assertion and skip the statistical layer. The population-scoring machinery earns its cost only where correctness is graded rather than binary: ranking, recommendation, generated text, OCR, forecasting, fraud scoring.

What a strong answer adds

That the expensive part is not the detector but the baseline. A quality time series is meaningless without a stable reference, and the reference has to survive model changes, prompt changes and traffic-mix changes, which means versioning it and re-baselining deliberately rather than letting it drift.