The AI Stack Is a System

Maggie Nanyonga · 2026-07-20 · Artificial Intelligence, AI Infrastructure, Software Architecture, MLOps, Engineering Management

Production AI fails at the interfaces while every component looks healthy. Twenty-two documented failure chains redraw the AI stack as a system, not layers.

Why production AI fails at the interfaces while every component looks healthy

The layer-cake problem

For most of August and early September 2025, the ordinary validation signals at Anthropic said nothing was wrong. Benchmarks passed. Servers reported healthy. Yet three separate bugs were degrading Claude in production at the same time: one misrouting requests to servers configured for the wrong context window, a second corrupting output (wrong characters mid-sentence, broken code) on Anthropic's own TPU servers. Users noticed. The company's evaluations did not. When Anthropic published its postmortem that September, it contained an admission worth reading twice: the evaluations the company ran "simply didn't capture the degradation users were reporting."

Hold that admission. A few months later, at Davos in January 2026, Jensen Huang gave the industry its most quotable picture of AI in years: a five-layer cake. Energy at the bottom, then chips, then infrastructure, then models, and applications on top. NVIDIA liked the image enough to publish its own elaboration around GTC. It is a good picture: memorable, teachable, correct about what the stack contains. Which is precisely why it deserves scrutiny. Good pictures get built on.

The layer view is not a strawman. It is how the industry organizes itself, mostly for good reasons: AWS's enterprise guidance for generative AI is built as a numbered layered approach, IBM's explainer states the premise plainly ("an AI stack organizes the elements into layers that work together"), and Red Hat draws five layers of its own. Layers give you separation of concerns, a hiring plan, a capital-allocation story, and a diagram a board can read. I will concede more: when I drafted the same map both ways, the layer version was easier to read, no contest, and I kept the vertical stack as a drawing convention. The cake earns its popularity.

What the cake also carries, silently in its geometry, is a theory of failure. Each layer is finished by its own team, verified by its own metrics, and handed upward; if every layer is verified, the system is verified. The Anthropic incident is a counterexample from the top tier of the industry: every component individually defensible, validation signals clean, the product degrading in users' hands for weeks. I will not call this the signature failure mode of all production AI; my evidence base is a register of twenty-two failure chains, not a census. I will call it what the register shows: a recurring and under-modeled failure class, in which component metrics fail to compose into system health, because the failures live at the interfaces between components and in the feedback loops that run from production back into everything: places the cake diagram literally has no line for. Cost, quality, safety, and availability are not properties of any layer. The incidents reviewed here, all from operators' own postmortems, filings, and one tribunal ruling, keep returning to that signature: metrics reporting one thing, the system delivering another, at an interface or a feedback path. And I will argue this is a topology problem, not an instrumentation shortfall. You cannot dashboard your way out of a wrong map.

One thing this article will not do is add a layer. The genre already exists: within weeks of Davos there were pieces arguing Huang's cake is "missing one critical ingredient." That response keeps the cake and inserts a tier, repeating the error it answers. The problem with the cake is not its inventory. The problem is its topology: dependencies that run in both directions, controls that cut across every level, loops that close from production backwards. No layer, organizational or technical, fixes a topology.

How this was researched. Before writing, I ran the source base through a screen of 108 primary documents: operator postmortems, status-page incident reports, SEC filings, a tribunal decision, specifications, and peer-reviewed papers, with full-text captures kept in an evidence register. From that base came fourteen interface contracts, one per consequential boundary in a production AI stack, and twenty-two failure chains. Every incident in this article comes from that register, and the appendix lists all twenty-two chains with dates, organizations, and primary-source links. Nothing here rests on a private dataset.

A note on vocabulary. I had to coin a few working terms, because the things they name have no settled names. Four carry real weight and get an asterisk at first use: domain, interface contract, feedback path, and the ownership rule. A short glossary at the end defines these and the rest, each with its nearest established relative; where a term extends existing practice, the glossary says whose.

1. The canonical stack, redrawn

Here is the map the evidence supports. A production AI stack partitions into five functional domains*: a physical and compute foundation (accelerators, drivers, interconnect, byte and object storage); compute and platform orchestration (admission, placement, multi-tenancy); data infrastructure (tables, catalogs, features, indexes, everything with data semantics); model and intelligence (training, model artifacts, serving engines and their internals, the model API surface); and context, retrieval, and applications (prompt assembly, retrieval pipelines, agent runtimes, the product). I say domain, deliberately, rather than layer. The names are mine; the components under them are documented practice. The difference is the partition rule: a component belongs to the domain whose contract it fulfills, not the domain it resides in or resembles.

The AI stack as an interdependent system: five domain boxes crossed by two cross-cutting plane bands, with five typed production-feedback return paths and interface-contract marks on the seams

Visual 1: The amended five-domain systems model. Five functional domains, two cross-cutting planes, five typed production-feedback paths (FP-1 to FP-5), and interface contracts on the seams. Not every documented interface is drawn (14 contracts, C01 to C14). Source: Canonical Architecture v1.0, structural freeze 2026-07-08.

That rule sounds bureaucratic until you apply it. vLLM's request scheduler schedules, and it stays in the model domain, because it schedules requests and cache blocks against a serving engine's internals, not workloads against a cluster. Airflow orchestrates, and it stays in data infrastructure, because the contract it fulfills is batch data-pipeline execution. Sort by resemblance and you get a tidy diagram of misassigned responsibilities. Sort by contract and every component acquires one primary accountable home, which will matter at ownership time.

Two functions do not fit the partition at all. Evaluation and assurance is one; governance, security, and operations is the other. I model each as a cross-cutting plane: a single function threaded through all five domains, with owned state and components physically hosted inside the domains it crosses. This extends established language rather than inventing it. NIST's AI Risk Management Framework states that "GOVERN is a cross-cutting function that is infused throughout AI risk management," and Open Policy Agent's entire design "decouples policy decision-making from policy enforcement." The plane picture takes those sources at their word. Evaluation is not a final exam before release; it is lifecycle gates at boundaries plus continuous monitoring streams running inside other domains' pipelines: TensorFlow Data Validation doing drift detection inside a data pipeline is evaluation-plane machinery resident in data infrastructure. The plane also splits two roles that layer thinking fuses: evaluation issues verdicts, from evidence it custodially owns, while operations executes the resulting action. The two stay distinct even when one pipeline implements both; that is what lets a verdict be invalidated later without rewriting history about who decided what. Governance, likewise, is not paperwork stacked on top. Its enforcement points (admission controls, catalog interception, inline safety filters) sit in the serving and data paths, where, as we will see with Gemini, they can fail with the blast radius of infrastructure.

Then there is the arrow the cake omits entirely: production feeding back. It is tempting to draw one return arrow labeled "feedback" and move on, and that temptation is itself a failure mode. The evidence supports five typed feedback paths*, each with its own producer, owner, timescale, and characteristic way of breaking: monitoring and drift telemetry to the evaluation plane; retraining data to data infrastructure, triggering the model domain; incident and audit evidence to the governance plane; evaluation verdicts back to release gates; and user or business outcomes to the application domain. MLOps practice covers pieces of this (continuous training, continuous monitoring), and Sculley and colleagues warned a decade ago about "boundary erosion, entanglement, hidden feedback loops, undeclared consumers"; but the pieces run at different clock speeds, from per-request telemetry to outcome attribution measured in quarters. The slowest and lossiest of these paths, business outcome back to operation, is the one that ended Zillow Offers.

Three bounds, before the failures. Everything in this article describes a single organization's AI stack; cross-organization supply chains are a different problem and a different piece. The domain boundaries are real but not static: Kubernetes' dynamic resource allocation has been relocating device allocation upward into orchestrator API objects release by release, while storage vendors absorb logical-table maintenance from below. And at least one core function refuses a fixed address altogether. Verified primary sources place retrieval inside the model (the founding RAG paper calls the retriever "a differentiable access mechanism to explicit non-parametric memory"), inside application code (the LangChain formulation), and in an external protocol service (the Model Context Protocol's servers, neither host application nor model). Any taxonomy that gives retrieval a single home is contradicted by a deployed formulation. A map whose boundaries move and whose functions are multiply homed is not a cake. It is a system, and the load-bearing parts of a system are the joints.

2. Interfaces are the architecture

Take any consequential boundary in that map and ask what actually crosses it. Not "data goes up," but specifically: what is guaranteed about what crosses, what evidence demonstrates the guarantee holds, who is accountable when it fails, and what change on either side forces those answers to be re-established. Write the answers down and you have what I call an interface contract*. The term has lineage: design-by-contract from software engineering, and the SLA/SLO discipline that Sculley's paper and NIST's generative-AI profile both invoke for ML boundaries ("well-defined contracts and service level agreements"). But as a named, six-part artifact for AI stack boundaries, it is my construction. Fourteen of them cover every domain boundary and both planes. Thirteen of the fourteen are crossed by at least one real, documented failure, and the fourteenth, the index-consistency seam, only by a failure chain derived step by step from verified contract clauses; no public incident has yet been caught crossing it, and it stays labeled hypothetical until one is. Two cautions on that ratio. First, the order of operations: the contracts were written before the incidents were mapped; the mapping is retrospective, and I expected to need new boundary types once real incidents started refusing to fit. I did not. Second, the fit is easier than it sounds: the failure classes combine, and most chains in the appendix carry two or three labels, so "crossed by at least one failure" is a weak test. The strong test is the appendix itself: all twenty-two chains with their primary sources, so the landing pattern can be checked rather than trusted.

Two of the six parts carry the planes into every seam: a gate clause (what must be re-verified before an artifact crosses the boundary) and a monitoring clause (what evidence must flow back after it crosses). That is NIST's split between pre-deployment measurement and post-deployment management, written where it can actually bind: at the boundary, not in a standards document nobody consults during an incident.

The context-assembly boundary sits between the model domain and the application domain, and in the layer picture the application is simply above the model: it assembles a prompt, hands it down, receives a completion. Now read the actual dependencies. The application's assembly choices are the model API's metered cost driver: provider-side prompt caching prices cache writes above base input rates and cache hits at a tenth of them, so how the application orders and reuses context directly sets the bill. That arrow points down. Meanwhile the model imposes constraints upward that the application cannot discover on its own side of the boundary: window limits, cache-breakpoint semantics, and the empirical finding from Liu and colleagues that model performance "significantly degrades when models must access relevant information in the middle" of a long context: a 2023 result on that generation of models; newer long-context models have blunted the curve, which is exactly the point: the constraint changes on the model side and must be rediscovered on the application side, version by version. So the ordering of documents inside a prompt is a quality decision, dictated by model internals, executed by application code. A boundary with obligations flowing in both directions is not an edge between layers. It is a contract between parties, and it deserves to be written like one.

Or take the seam between data infrastructure and retrieval. A vector index is valid only relative to the embedding-model version that produced it; embed queries with version N+1 against an index built at version N and you get plausible neighbors, silently wrong, with no error signal anywhere. So the contract at this seam pins the embedding version, and a version change fires a coordinated event: a rebuild owned by data infrastructure, accepted or rejected by the retrieval owner. A decision inside the model domain reaches down into data infrastructure and invalidates state there. The layer diagram has no arrow for a higher layer breaking a lower one; it gives you no place even to draw this failure, let alone assign it.

The most instructive seam of all replaces two layers entirely. Where does physical storage end and the data platform begin? In production the answer is a single operation: the atomic metadata commit. Apache Iceberg's specification puts the entire logical table into ordinary objects in the object store, with one externality: "all changes to table state create a new metadata file and replace the old metadata with an atomic swap." Below that commit, bytes; above it, semantics. And the seam has survived its hardest test. Amazon's S3 Tables absorbed table compaction and snapshot maintenance into the storage service itself, a vendor eating the layer above it, yet the vendor's compaction is still written as the most recent Iceberg snapshot, still deferring to logical-layer retention configuration. The components migrated. The seam held. Layers are wherever this year's product packaging says they are; a well-chosen seam outlives the vendors on both sides of it.

One clause makes contracts operable rather than ceremonial: the revalidation trigger. Standards already gesture at it. NIST's secure-development profile for generative AI, a voluntary companion to its SSDF, recommends retesting AI models "when they are retrained or new data sources are added." The contract generalizes the idea to every seam, with one scoping rule. Triggers fire on changes to seam semantics: the commit operation, the visibility guarantees, the embedding version, the served configuration. They do not fire on mere vendor or operator changes, because a trigger that fires on everything is ignored within a quarter, and an ignored trigger is worse than none. Three of the four incidents below are, at bottom, a revalidation trigger that did not exist.

3. Four incidents the cake cannot draw

I classify stack failures into five classes: component failures, interface failures, system failures, feedback-loop failures, and ownership failures. The scheme is mine, and it sorts not by severity but by which divergence occurred between what was reported and what was delivered. Component failures, where a thing simply breaks and says so, are the well-covered class; every layer diagram and every on-call rotation already handles them. The other four are where the expensive surprises concentrate, and each of the four incidents below instantiates one. All four are told from primary documents: an engineering postmortem, an SEC-filed shareholder letter, a tribunal's reasons for decision, and an operator's incident report.

Anthropic, August–September 2025. Return to the opening scene, because the mechanics are the argument, and the mechanics were three distinct faults. First, a routing error: some Sonnet 4 requests were "misrouted to servers configured for the upcoming 1M token context window" (the 1M-token beta shipped publicly on August 12), and a routine load balancing change on August 29 made it worse. Session stickiness amplified it: once a conversation landed on the wrong server class, follow-ups tended to land there too, converting an intermittent fault into a persistent per-user degradation. At the worst hour, on August 31, 16 percent of Sonnet 4 requests were affected, and roughly 30 percent of Claude Code users had at least one message routed to the wrong server type during the period. Second, on Anthropic's first-party TPU servers, a deployed misconfiguration under which "a runtime performance optimization occasionally assigned a high probability to tokens that should rarely be produced given the context." This bug, not the routing, produced the Thai and Chinese characters surfacing mid-sentence in English answers and the syntax errors creeping into generated code, and it never touched third-party platforms. Third, a token-selection code change that "inadvertently triggered a latent bug in the XLA:TPU compiler": the approximate top-k operation used in token selection could return outright wrong results under certain batch sizes and configurations, a defect masked by a December 2024 precision workaround until that workaround was removed. It was confirmed for Claude Haiku 3.5, again first-party only.

Now place each fault on the map. Bug one broke the orchestration–serving seam and, through it, the context-assembly contract: the served window configuration no longer matched what the application side assumed. Bug two broke the serving path's sampling behavior. Bug three needs more care, because a skeptic will call it a plain component failure, and the skeptic is half right: a compiler returning wrong results is a broken component by any ordinary definition. What lived at the accelerator–model seam was the detection: the defect had been masked since December 2024 by a precision workaround, and when the workaround was removed, nothing forced the assumptions it had been protecting to be re-verified. The fault was a component's; its only chance of being caught was a seam's. Two seam faults, one component fault detectable only at a seam, and not one component metric moved. Orchestration saw healthy servers, because the servers were healthy; they were the wrong healthy servers. The TPU fleet saw a valid optimization. The compiler surfaced no fault; the bug was latent. Benchmarks and evaluations stayed green throughout. The effective detection system was users complaining that Claude got dumber, and even then, the postmortem records, the overlapping faults produced "a confusing mix of reports that didn't point to any single cause," while privacy controls limiting engineers' access to user interactions hampered the investigation. The blast radii differed, instructively. The two output-corrupting bugs stayed on Anthropic's own serving stack. The misrouting crossed surfaces: mostly Anthropic's own API, with far smaller peaks on Amazon Bedrock (0.18 percent of Sonnet 4 requests) and Google Cloud Vertex AI (under 0.0004 percent), each platform relaying degradation it had no way to detect. Fixes rolled out between September 2 and 18. For the compiler bug, Anthropic switched from approximate to exact top-k sampling, accepting a performance cost for the sake of correctness.

What this shows: no model regressed here, and only one component actually broke, silently. What turned three local faults into weeks of user-visible degradation was the seams, and the evaluation plane saw none of it. This is the system-failure class in its purest observed form, the user-horizon outcome failing while every local signal stays acceptable. Adding a named layer to the diagram would not, by itself, have created the missing cross-boundary signal; nothing was missing from the inventory. What was missing was a line between the boxes with a test on it.

Zillow Offers, 2021. Zillow's iBuying business rested on a stated ambition, "to become a market maker, not a market risk taker," which required forecasting home prices three to six months out, inside unit-economic guardrails of plus or minus 200 basis points of breakeven. In 2021 the housing market moved at what the company called an unprecedented rate, and the forecasting model's error left its modeled envelope: "we have been unable to accurately forecast future home prices at different times in both directions by much more than we modeled as possible." So far, an ordinary story about a hard prediction problem.

What makes it a stack story is the loop wrapped around the model. Forecasts set offer prices; offers became purchases, 9,680 homes in the third quarter alone; purchases became inventory carried on the balance sheet at prices the market would not return. And while the loss compounded, the operation's headline metric improved. The shareholder letter's own words: "we experienced higher conversion rates than previously observed in Zillow Offers as a result of unintentionally purchasing homes at higher prices than our current estimates of future selling prices." Sellers accept above-market offers eagerly. Conversion did not merely fail to flag the failure; it inverted, reporting the failure as success, and the operation kept buying. There was a throttle, and it eventually fired: Zillow suspended new purchase contracts in October, after the position had been accumulated. Mitigation, not prevention. Two links in that chain are my inference rather than the letter's statement (the seller's side of the trade, and the loop running slower than the market), though the letter supports both.

The bill arrived at quarterly-filing speed: a \$304 million write-down on inventory, attributed in the letter to buying homes above expected selling prices; average gross profit per home of negative \$80,771; unit economics swinging roughly 1,200 basis points from Q2 into an expected negative 500 to 700 for Q4; then the wind-down of the entire business and a roughly 25 percent workforce reduction. One correction to the tidy version of this story: the wind-down decision was not the forecast error alone. The letter also cites renovation and resale capacity constraints, a difficult labor and supply-chain environment, conversion of only about 10 percent of serious sellers, and the equity capital and earnings volatility that scale would have demanded. Forecast volatility was the trigger, interacting with all of it. Through everything, the model stayed available, serving forecasts without a single component alarm.

What this shows: a feedback-loop failure as the central mechanism, not the sole cause. The path from realized outcomes back to the forecast and the purchasing throttle existed, but it ran on a quarter's clock against a market moving in weeks, and the one fast signal in the loop pointed the wrong way. The other causes the letter names grew in the room that slow loop created.

Moffatt v. Air Canada, decided 2024. After their grandmother died in November 2022, Jake Moffatt asked Air Canada's website chatbot about bereavement fares. The chatbot told them they could book now and "submit your ticket for a reduced bereavement rate" within 90 days. It even linked, helpfully, to the airline's bereavement-travel policy page, which said the opposite: the policy "does not apply to requests for bereavement consideration after travel has been completed." They booked on November 11, relying on the answer; the airline later refused the retroactive fare. Before British Columbia's Civil Resolution Tribunal, Air Canada argued that it "cannot be held liable for information provided by one of its agents, servants, or representatives — including a chatbot," in effect, the tribunal wrote, that the chatbot "is a separate legal entity that is responsible for its own actions." The ruling dismantled this in two sentences: "It should be obvious to Air Canada that it is responsible for all the information on its website. It makes no difference whether the information comes from a static page or a chatbot." And of the customer's reliance: "There is no reason why Mr. Moffatt should know that one section of Air Canada's webpage is accurate, and another is not." Air Canada was found to have "not take[n] reasonable care to ensure its chatbot was accurate" and ordered to pay \$812.02 in damages, interest, and fees. The dollar figure is the least important number in this article. Look instead at the internal record: months before the tribunal ruled, an Air Canada representative had already conceded in email that the chatbot had provided "misleading words," and had "noted the issue so it could update the chatbot." An after-the-fact content fix, which is the whole finding in miniature: nothing stood in front of the answer, only cleanup behind it. And look at the dashboards. The bot was up, responsive, fluent, and it linked to a valid page, so even a link-integrity check would have passed. The correct policy existed the entire time; it simply was not enforced at the boundary where the answer met the customer, because no team owned the consistency between what the chatbot said and what the policy page said.

What this shows: an ownership failure. A cross-boundary outcome, answer correctness against authoritative policy, that no accountable party held, until a tribunal performed the ownership assignment the organization had declined. One caution on weight: this is a small-claims tribunal decision, binding on nobody, not even the tribunal itself, so treat it as an early warning signal rather than settled precedent. But the signal is unusually legible. The first adjudicator asked concluded that the operator owns the complete outcome of an AI-mediated answer.

Gemini, February 27, 2026. At 04:37 Pacific time, error rates began climbing across every Gemini model version on Google's Vertex AI, in multiple regions at once. The models had not changed. What had changed, per Google's incident report, was "a configuration change to a safety filtering service that supports all Gemini models," which "created code paths that eventually led to service disruptions and capacity loss." A safety filter is governance machinery, an enforcement point in the vocabulary of Section 1, and it sits physically in the inference path. That placement is deliberate: an enforcement point you can route around is not enforcing anything. But non-bypassability cuts both ways. Whatever every request must transit, every request can be stopped by, and because this one filter "supports all Gemini models," one component's capacity loss became the whole fleet's shared fate. The loss surfaced as two different errors sorted by billing plan: 429 resource-exhausted for pay-as-you-go customers, 503s for provisioned throughput. Same upstream cause. To Google's credit, detection worked: automated monitoring alerted engineers at 04:54, seventeen minutes after onset. They identified the faulty configuration, rolled it back, added capacity; the whole event lasted about two hours. But per-model and per-customer views can obscure a shared dependency, and Google's own remediation list names the gaps in its own words: "reinforcing rollout processes to include mandatory validation checkpoints," meaning the enforcement point had not itself been treated as a gated, evaluated artifact, and "improving alerting systems to monitor critical dependencies more closely," meaning the shared chokepoint deserved a closer watch than it had.

What this shows: an interface failure at the governance seam, in the exact place a layer diagram would file under compliance and forget. A governance component failed as infrastructure, with fleet-wide blast radius, because the plane is physically in the path. This was simultaneously a governance incident and a serving incident, and any model that files it under only one heading will misroute the next one.

Four incidents, four failure classes, four seams, four detection stories: users, a quarterly filing, a tribunal, an error-rate spike. In every case the components were, on their own terms, fine, and what failed was a line the cake does not draw.

4. Local metrics versus system outcomes

There is a reason the pattern recurs, and it is not that these four operators were careless. Local metrics measure a component's fulfillment of its own inputs: uptime, latency, utilization, benchmark scores. What the business needed measured was the outcome at the far end of a chain of seams (call these system-level metrics), and the two kinds can point in opposite directions indefinitely. A system can be fully available and entirely wrong; nothing in an uptime number even refers to whether the answer was right.

Each incident in Section 3 names its own missing metric. Anthropic: output quality at the user-experienced horizon, correlated against the serving configuration actually used: a metric that spans three domains and therefore belonged to none of them. Air Canada: a policy-consistent answer rate at the answer boundary, itself an open measurement problem, since grading answers against a policy corpus is not solved, but no ordinary chatbot dashboard even attempts it. Google: cross-fleet enforcement-point health, the view that would have said a dozen simultaneous mysteries were one event, and the view its remediation now promises to watch more closely. In each case the data to compute the missing metric existed; the metric did not, because every metric in production had been scoped to a box and the failure lived on an edge. Anthropic's remediation concedes exactly this: more sensitive evaluations running continuously and directly on production systems: instruments aimed at the horizon where the failure had been visible.

Zillow deserves its own paragraph, because it is the strongest instance I have found of something worse than a blind spot. Conversion rate was not blind to the failure; it encoded the failure and reported it as success, because the same over-pricing that guaranteed the loss also guaranteed sellers would accept. Call this the inverted proxy, and note what produced it: the metric was chosen because it was easy to collect and had always correlated with health. The system-level metric the operation needed, forecast selling price against realized selling price per cohort, tracked live at the purchasing horizon, was harder and slower. The letter leaves open whether that metric was absent, or present and outweighed by the appetite for inventory, and the distinction matters less than it seems, because a metric that does not govern the buying is missing from the loop either way. The general rule costs one sentence and most organizations still have not paid it: any proxy that is cheaper than the outcome it stands for will, under precisely the conditions that matter, stop standing for it.

Cost follows the same grammar, stated here as mechanism rather than statistic, because the observed evidence base for AI cost blowouts is thinner than the discourse pretends. Per-token and per-call prices are local metrics; the system-level quantity is cost per successfully completed task. The context-assembly contract from Section 2 shows where the two diverge: assembly and caching patterns are the metered driver at the model API boundary, so an application that assembles context wastefully can hold every per-call number steady while the cost of each completed outcome climbs. Meter only the calls, and you will discover this the way Zillow discovered its forecast error: downstream, in the finance department, in a currency nobody can argue with.

5. Ownership and revalidation

Ownership is not a management footnote to this architecture; it is part of the load path. I will not claim that every seam fails organizationally before it fails technically: that is tidier than the record. What the record does support is narrower and more useful: the consequential failures hardened where ownership was implicit. The cake endures partly because it doubles as an org chart, one layer per team, each accountable for its box, the seams between boxes accountable to nobody. Reject the cake's topology and you take on a debt, because cross-cutting planes and dual-homed components create exactly the ambiguity that "everyone's job is no one's job" describes. A model that creates that ambiguity owes a rule that resolves it.

My answer is the dual-membership ownership rule*, and it is blunt. Every component that lives in one place and serves another gets five fields: a primary accountable owner (the domain whose contract it fulfills, never merely where it runs); a residence owner for hosting concerns; failure classification by breached contract clause, not by where the process ran; SLO responsibility with the primary owner; and cost attribution following the contract meter. A guardrail executing inline in the serving path is owned by the governance plane and hosted by serving: a latency spike in it that breaches the policy clause is a governance incident, and the same spike breaching the serving SLO is additionally a serving incident, both routed, neither orphaned. The register's closing line: a dual membership without a named accountable owner is an ownership failure: not a risk of a failure, a failure whose incident has not yet arrived.

Moffatt v. Air Canada is this rule enforced from outside. A chatbot is a boundary artifact: it belongs wholly to neither the application team that deploys it nor the policy organization whose content it speaks, and a boundary artifact cannot own its own outcome, which is precisely why a named human owner is mandatory. Air Canada's tribunal argument attempted the opposite move, pushing ownership not just off a team but off the organization entirely, onto the artifact itself. The tribunal's answer generalizes far beyond airlines: ownership of an AI-mediated outcome rests with the organization whose contract the artifact fulfills, and if you do not perform that assignment internally, some external party (a tribunal, a regulator, a headline) will perform it for you, on their terms. An early reading from a small tribunal, yes; early readings are what operating decisions get made on.

A subtler ownership lesson sits inside the incidents. In the Anthropic case, each seam had a plausible local owner (routing, serving, compilers, evaluations), and yet the composite user outcome, the only place where the three faults were jointly visible, had no owner below the postmortem itself. In the Zillow case, the model had owners and the purchasing operation had owners, but for the complete chain (forecast error becoming purchase commitments becoming balance-sheet loss), the letter gives no evidence that anyone below the executive suite held it before it surfaced as a write-down. Local ownership everywhere; composite ownership nowhere. The precise phrasing matters: not "nobody owned it," but no accountable owner held the complete outcome, the evidence path, and the authority to interrupt the loop, all three at once. That triple is what an interface owner actually is.

My map has two holes I have not closed: the labeling capacity that bounds how fresh retraining data can be is owned by no domain, and the classification of scale-to-zero decisions at the orchestration seam is unassigned. They are holes, recorded and open.

Ownership answers who; revalidation answers when. The revalidation trigger from Section 2 becomes concrete the moment you wire it to the incidents. An embedding-version change fires a gated index rebuild. A change to an enforcement point fires re-evaluation of the point and invalidation of every assurance verdict that depended on it, close to word for word the gate Google's "mandatory validation checkpoints" remediation now adds in front of the Gemini safety filter. The routing case needs the scoping rule most, because routing and load-balancer changes at a serving fleet are constant, and a trigger on all of them would be ignored within the quarter Section 2 predicted. The trigger belongs on the served-configuration map: which server classes, with which context-window and cache semantics, a given request class can land on. The August 29 load-balancer change was routine; the seam-semantics change had already happened when servers configured for the 1M-token window entered the pool that standard Sonnet 4 requests could reach. A trigger scoped there fires rarely, and it would have surfaced the misrouting as a configuration diff to be revalidated rather than weeks of user complaints to be triaged. None of this is exotic. It is the retesting NIST already recommends when models are retrained or data sources change, owed at every seam and scoped to seam semantics so the trigger stays rare enough to be obeyed.

On coordination mechanics I will be brief; the subject deserves its own article. The pattern that works is a named owner per interface, a shared SLO spanning the seam, and a change-triggered gate: standing machinery, in the path. Committees and escalation matrices are where seams go to be discussed rather than owned.

6. Six rules for a stack that is a system

Everything above compresses into six rules. None is a purchase. Each is a decision, currently sitting undecided in most organizations; that is the entire cost and the entire obstacle.

Partition by contract fulfilled, not by residence or resemblance. If you cannot say which contract a component fulfills, you have found either a component you do not understand or a contract you have not written. Both discoveries are worth the exercise.

Write the seam down. For each consequential boundary: what crosses, what is guaranteed, what evidence proves the guarantee, who is accountable, and what change forces re-verification. One page per seam. The Anthropic incident crossed three seams; ask how many of your own equivalents have even one of those five answers written anywhere.

Treat evaluation and governance as planes, in the path, with owned state. A safety filter can take down your whole fleet; that is the practical meaning of "in the path," and it cuts both ways: enforcement points must themselves be gated, monitored, evaluated artifacts. And silence from any monitor must itself be an alarm; a dead monitor looks exactly like a healthy quiet system.

Type your feedback paths and clock them against the world. Name each loop's producer, owner, timescale, and failure mode, then compare the loop's speed to the speed of the environment it corrects. Zillow's loop was directionally correct and a quarter too slow, and that delay, compounded through purchasing, was the central mechanism of the loss, the one the letter's other causes compounded around.

Instrument the outcome, and treat easy proxies as suspects. For each product built on the stack, one metric that measures the outcome (task completed, answer consistent with policy, cost per success, forecast against realized), owned by a named person. Any proxy that can rise while the outcome falls eventually will.

Name an owner for every dual-homed component, and revalidate on seam-semantics change. The five-field block, applied to your guardrails, operators, indexes, caches, and chatbots, with special attention to boundary artifacts, which cannot own their own outcomes. Then wire the triggers, scoped tightly enough to be obeyed, so that revalidation happens before production performs it for you.

Where this ends, and what we still cannot see

The claim of this article fits in four sentences. The AI stack is a system, not a sequence of handoffs. Its consequential design decisions live at interfaces, which therefore require explicit design: contracts, not adjacency. Production feedback, under its typed-path contracts, closes loops back into data, models, evaluation, and policy, and those loops are architecture, not plumbing. And no layer can claim system success alone, because system success is not a property any layer has.

I owe you the limits of the evidence. The claims rest on seventeen observed public incidents plus the pattern evidence around them, all listed in the appendix, within the single-organization scope declared at the outset: enough to demonstrate that each failure class is real, not enough to estimate frequencies, and I have deliberately claimed none. Some placements in the map are contested by design; retrieval's three verified homes are the honest state of the field. And three failure modes I have named, I cannot yet show you. Grader drift: evaluation scores silently ceasing to be comparable across rounds as judges and baselines shift. Agentic cost amplification: per-call metrics staying healthy while looping agents multiply the cost of each completed task. Physical throttling and distributed workload stalls: goodput degrading below any availability alarm. No observed public incident in my evidence base instantiates them end to end, which is why they appear here as observability frontiers rather than findings. What follows is a hypothesis, not a finding: I suspect at least one of the three is happening somewhere in production right now, unmeasured, because each would be visible only in a system-level signal that standard dashboards do not compute. If your instruments cannot falsify that suspicion for your own stack, then for your stack it is not a suspicion you have ruled out. It is one you cannot rule out.

Huang's cake will outlive this article, and as an inventory it deserves to; it is right about what the stack contains and useful for deciding what to buy. Keep it for that. But the failures reviewed here did not live in the inventory. They lived in the arrows: the dependency running the wrong way, the plane cutting through every tier, the loop closing a quarter late, the seam nobody owned. And they arrived wearing green dashboards. The fix was never another layer, and it was never more dashboards. Redraw the map: contracts at the seams, owners on the contracts, triggers on the changes, and one metric, owned by one person, that measures whether the system did what all those healthy components exist to do.

Appendix: the incident evidence base

Every failure chain in the research behind this article, from the incident register compiled 2026-07-08. Seventeen chains are observed public incidents with published primary reports; three (CH17–CH19) are non-AI analogs included for pattern support only; CH21 is a pattern chain anchored in peer-reviewed literature rather than a single incident; CH22 is the derived scenario discussed in Section 2, with no observed public incident yet. Chains CH01, CH14, CH15, and CH12 are the four told in full in Section 3. Failure-class labels use the five-class scheme from Section 3; real chains usually combine classes, so each entry lists its primary class first with contributing classes after it.

| Chain | Incident | Date | Organization | Primary source | Failure class |

|---|---|---|---|---|---|

| CH01 | Three overlapping infrastructure bugs degrade Claude response quality while evaluations stay green | Aug 5 – Sep 18, 2025 | Anthropic | https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues | System + interface + feedback-loop (evaluation plane) |

| CH02 | Inference-kernel fault on specific GPU configurations corrupts token selection while availability stays green (ChatGPT "gibberish") | Feb 20–21, 2024 | OpenAI | https://status.openai.com/incidents/ssg8fh7sfyz3 | Component → system, via interface |

| CH03 | User-feedback reward signal weakens the primary reward signal; evaluation gate misses a behavioral regression (GPT-4o sycophancy) | Apr 25–28, 2025 (report May 2) | OpenAI | https://openai.com/index/expanding-on-sycophancy/ | Feedback-loop + evaluation |

| CH04 | Cache-lifecycle and prompt-artifact faults degrade Claude Code quality outside the tested envelope | Mar 4 – Apr 20, 2026 (postmortem Apr 23) | Anthropic | https://www.anthropic.com/engineering/april-23-postmortem | Interface (context assembly) + feedback-loop + system |

| CH05 | Internal-network congestion with self-hosted monitoring blinded, cascading to control-plane impairment (US-EAST-1) | Dec 7, 2021 | Amazon Web Services | https://aws.amazon.com/message/12721/ | Feedback-loop (retry amplification) + system |

| CH06 | Observability-instrumentation deployment overwhelms the Kubernetes control plane, breaking DNS service discovery | Dec 11, 2024 | OpenAI | https://status.openai.com/incidents/ctrsv3lwd797 | Feedback-loop + system, with interface element |

| CH07 | DNS-automation race empties a data-layer endpoint; health-check feedback withdraws healthy capacity (DynamoDB) | Oct 19–20, 2025 | Amazon Web Services | https://aws.amazon.com/message/101925/ | Feedback-loop + system, with interface element |

| CH08 | Blank-field policy replicated globally crashes the API-management chokepoint; restart herd extends recovery (Service Control) | Jun 12, 2025 | Google Cloud | https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW | Interface (schema breach) + feedback-loop → system |

| CH09 | Maintenance command plus an inert safety gate collapses the control plane; recovery depends on the failed path (BGP/DNS) | Oct 4, 2021 | Meta | https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/ | System + interface (gate did not fire) + ownership |

| CH10 | Maintenance automation deschedules network control-plane jobs across locations; config scope propagated beyond intent (#19009) | Jun 2, 2019 | Google Cloud | https://status.cloud.google.com/incident/cloud-networking/19009 | Interface (blast-radius breach) + system |

| CH11 | Datacenter power cascade takes down a "redundant" control plane with undiscovered hard dependencies on one facility | Nov 2–4, 2023 | Cloudflare | https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/ | System (hidden cross-layer dependency) + ownership |

| CH12 | Config change to one in-path safety-filter enforcement point fails as a serving outage across every Gemini model (Vertex AI) | Feb 27, 2026 | Google Cloud | https://status.cloud.google.com/incidents/41E5S3mkTGDfkZuJZH5k | Interface (governance seam) + system |

| CH13 | Ingested customer data contaminates a targeting model's training corpus with no quality gate at the data→model seam (~\$110M, Audience Pinpointer) | disclosed May 10, 2022 | Unity Software | https://s26.q4cdn.com/977690160/files/doc_financials/2022/q1/Q1-2022-Prepared-Remarks.pdf | Feedback-loop + interface |

| CH14 | Price-forecasting model's error compounds through an operational purchasing loop that outran its update cadence (Zillow Offers wind-down) | Nov 2, 2021 | Zillow Group | https://www.sec.gov/Archives/edgar/data/1617640/000161764021000085/exhibit993.htm | Feedback-loop + system |

| CH15 | Customer-facing chatbot contradicts the authoritative policy page; no team owns the answer's correctness (Moffatt v. Air Canada) | Nov 11, 2022 (ruling Feb 14, 2024) | Air Canada (adjudicated by BC Civil Resolution Tribunal) | https://decisions.civilresolutionbc.ca/crt/crtd/en/525448/1/document.do | Ownership + interface |

| CH16 | Adversary-controlled production interactions cross into learned model behavior with no gate between outcome path and learning path (Tay) | Mar 23–24, 2016 (response Mar 25) | Microsoft | https://blogs.microsoft.com/blog/2016/03/25/learning-tays-introduction/ | Feedback-loop + governance/ownership |

| CH17 (non-AI analog) | Content-validator gate passes a field-count-mismatched artifact, deployed without canary (Channel File 291) | Jul 19, 2024 | CrowdStrike | https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf | Interface (schema breach) → system, via gate bypass |

| CH18 (non-AI analog) | WAF rule bypasses the canary path; unprofiled backtracking regex exhausts edge CPU globally | Jul 2, 2019 | Cloudflare | https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/ | Interface/system (release-path exemption) + ownership |

| CH19 (non-AI analog) | Partial deploy leaves a repurposed flag activating discontinued code; no automated pre-trade chokepoint (Knight Capital) | Aug 1, 2012 (SEC order Oct 16, 2013) | Knight Capital (adjudicated by U.S. SEC) | https://www.sec.gov/files/litigation/admin/2013/34-70694.pdf | Interface (semantic mismatch) + ownership → system |

| CH20 | Redis client cancellation race returns another user's cached data; no read-time isolation check owns the invariant (ChatGPT) | Mar 20, 2023 | OpenAI | https://openai.com/index/march-20-chatgpt-outage/ | Interface (cache-seam isolation breach) + ownership → system/security |

| CH21 (pattern chain) | Training–serving skew: offline and online feature paths diverge under green component metrics | (anchor paper 2015) | (anchor: Sculley et al., Google, NeurIPS 2015) | https://proceedings.neurips.cc/paper_files/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf | Interface (feature-semantics breach) with feedback-loop tail |

| CH22 (derived scenario) | Silent index staleness: an embedding-version change without coordinated rebuild mis-grounds RAG generation; no observed public incident yet | (derived) | (derived from the index-consistency contract clauses; coupling anchor: Lewis et al.) | https://arxiv.org/abs/2005.11401 | Interface (retrieval-correctness invariant) |

References

Glossary of working terms

Terms marked with an asterisk in the text (domain, interface contract, feedback path, ownership rule) plus the working coinages used unstarred. Each entry names its nearest established relative.

Research method, evidence register, and archived sources: available from the author on request.

— Maggie Nanyonga