§II.1 Why layers matter for harm analysis

When a person is harmed by an AI chatbot's output — when, in the cases described in Part I, a chatbot conversation contributed causally to a death — the harm did not arrive in the world fully formed at the moment the user read the message on their phone. The harm is the end of a chain that starts much earlier: with the data that trained the model, with the training methodology that shaped what the model would say, with the safety-evaluation process that decided which model behaviors were acceptable to deploy, with the deployer's choice of which API to build atop, with the user-interface design that put the message in front of the person, and with the post-deployment monitoring (or its absence) that did or did not flag the conversation as something that needed intervention.

That chain is what we mean by "the AI ecosystem." It is not a single company; it is not a single product; it is a stack of layers, each operated by different teams (often at different companies, often in different jurisdictions), each making decisions that affect what the end user eventually experiences. Each layer is a potential intervention surface — a place where harm can be prevented. Each layer is also a potential legal-attribution surface — a place where, when harm has not been prevented, legal responsibility might attach. The cases of Part I, almost without exception, name multiple layers: the foundation-model provider (where the model was trained), the deployer (where the chatbot product was operated), and sometimes the hosting infrastructure (where the deployer's product ran).

A reader who thinks of "AI" as a single thing will struggle to understand how a wrongful-death suit against a chatbot company can also reach the foundation-model provider whose technology underlies the chatbot. A reader who understands the layered ecosystem will see immediately why the suits are structured the way they are: the lawsuits are tracing the chain backwards, layer by layer, from the harm to the source.

This Part introduces the layered ecosystem at the level needed to make Part III — the per-layer walks where the technical and legal issues at each layer are treated in detail — legible. It does not aim to be a comprehensive technical exposition of AI; that would require a different document. It aims to give a reader new to this material the conceptual scaffolding they need to follow the legal arguments downstream.

GRAD-INTERN — Layer analysis is doctrinally consequential, not merely descriptive

Layer-by-layer analysis of AI products is not a stylistic preference; it is a doctrinal requirement for several causes of action. Product-liability doctrine asks where the defect was introduced — design, manufacturing, or warning — and "where" in a layered software-and-services product means which layer. Causation analysis in tort asks how the harm proximately resulted from the defendant's conduct, which in a layered product requires tracing the conduct through the layer at which the defendant operated. Discovery scoping asks what documentation needs to be produced from each defendant, which depends on which layer that defendant operated. Component-part-manufacturer doctrine — keeping a foundation-model provider in the case after Conway in Garcia — explicitly recognizes that different layers of the same product chain support different liability theories. The legal landscape Part IV maps cannot be applied to the cases of Part I except through the layer analysis. Treating "AI" as a single homogeneous defendant misframes every interesting doctrinal question. Treating it as a layered ecosystem opens the doctrinal questions to the answers each layer's facts can supply.

§II.2 The academic ecosystem-analysis tradition + our extension

Analyzing artificial intelligence as a layered ecosystem — a stack of dependent layers operated by different actors, with harm-attribution and intervention surfaces running between them — is an established analytical mode in academic literature. Two papers from the Stanford Center for Research on Foundation Models (CRFM) establish the academic substrate this site builds on.

Bommasani et al., On the Opportunities and Risks of Foundation Models (Stanford CRFM, 2021), introduces the term foundation model to describe the class of models (BERT, GPT-3, DALL-E, and their successors) trained on broad data at scale and adaptable to a wide range of downstream tasks. The paper's core observation for our purpose: "the defects of the foundation model are inherited by all the adapted models downstream." That is, harm-relevant properties present at the foundation-model layer propagate through every subsequent adaptation, deployment, and consumer-facing product. The downstream-dependency framing is precisely the doctrinal-relevant substrate that the cases of Part I trace backwards through when they name foundation-model providers as upstream defendants. (Source: Bommasani et al. 2021, arXiv:2108.07258, "On the Opportunities and Risks of Foundation Models"; pinned in our research corpus, chunk-hash a9b3bcee T3.)

Bommasani et al., Ecosystem Graphs: The Social Footprint of Foundation Models (2023), extends the analysis to what the authors term the "broader sociotechnical ecosystem" of foundation models. The paper proposes documenting that ecosystem as a graph of "assets (datasets, models, applications) linked together by dependencies that indicate technical (e.g. how Bing relies on GPT-4) and social (e.g. how Microsoft relies on OpenAI) relationships," with metadata at each asset and dependency. As of March 2023 the paper documents 262 assets (64 datasets, 128 models, 70 applications) from 63 organizations linked by 356 dependencies. The assets-and-dependencies framing makes the cross-layer dependency structure explicit at the granularity needed for cross-layer attribution analysis. (Source: Bommasani et al. 2023, arXiv:2303.15772, "Ecosystem Graphs: The Social Footprint of Foundation Models"; authored by the Stanford CRFM; pinned in our research corpus, chunk-hash d0ef4c36 T3.)

This academic tradition is the substrate we build on. The two papers establish that AI systems are appropriately analyzed as a layered ecosystem of dependent assets and that documentation of those dependencies is methodologically tractable. The papers do not, however, organize the layered analysis around the question this site asks: where does AI-generated harm originate, and where can it be prevented or remedied? For our purpose, we reshape the analysis into seven harm-relevant layers (Part III) organized around that question, treating cross-layer dependencies as harm-attribution surfaces in the legal sense as much as in the technical sense.

The harm-relevant layers our reshape surfaces — at the granularity needed for legal-attribution analysis, which the academic ecosystem tradition does not always foreground at this granularity:

• Pre-training data curation — what is in the training corpus, and how the corpus is filtered, de-biased, or scoped. Harm-output prevention starts here, before the model has been trained on a single example.
• Alignment training methodology — Reinforcement Learning from Human Feedback (RLHF), Constitutional AI, RLAIF, and related methods that shape what the model will and will not say. The choices made here are a primary determinant of harm-output risk in deployed products.
• Red-team practices — adversarial testing of models for harmful outputs before deployment. METR, Anthropic, and OpenAI all maintain published descriptions of their red-team practices; CISA's TEVV framework treats red-teaming as one component of a broader Testing-Evaluation-Validation-Verification regime.
• Safety evaluation / TEVV — Testing, Evaluation, Validation, Verification of model behavior; the documentation regimes that record what was tested, what was found, what was changed.
• Post-deployment monitoring — production telemetry; abuse-pattern detection; the systems that watch deployed products in operation and that may (or may not) flag harm-pattern conversations for intervention.
• Trust & Safety (T&S) operations — content moderation; user reports; account actions; the human-and-system layer between policy and practice on deployed products.
• Policy / communications — public statements; transparency reports; regulatory-affairs liaison; the layer that interfaces between the lab and external scrutiny.
• Legal / compliance — terms of service; privacy policy; regulatory filings; litigation defense; the layer that interfaces between the lab and the formal legal system.
• External-facing constraints — usage policies; API terms of service; minor-protection product flags; age-gates; the operational rules that downstream users and deployers must follow.
• Application layer (deployers) — third parties that build atop frontier APIs (such as Character.AI, which built atop earlier model technology before pivoting); integrators; resellers; chatbot products. This is where most consumer-AI products users actually interact with live.
• Hosting / infrastructure — cloud providers; CDN; identity/auth. The "plumbing" layer; named in Garcia as the basis for keeping Google in the case as a "component-part-manufacturer."
• End-user surfaces — chat UIs; mobile apps; embedded chatbots; the surface where harmful output reaches a person.

Each of these layers is where harm-prevention work happens (or does not happen) and where legal-attribution analysis lives (or does not live). The academic ecosystem tradition cited above establishes that documenting dependencies between layers is methodologically tractable; this site's contribution is organizing the layered structure around the specific harm-and-legal-attribution question, at the granularity where doctrinal arguments operate. Part III walks step into each layer in turn.

GRAD-INTERN — Why granularity-of-layer-decomposition is doctrinally consequential, not stylistic

The granularity at which an AI ecosystem is decomposed into layers is not a stylistic preference; it is a doctrinal lever. Product-liability doctrine asks where the defect was introduced; component-part-manufacturer doctrine asks which actor at which layer supplied which load-bearing component; proximate-cause analysis asks which layer's conduct most-directly produced the harm. Each doctrinal question presupposes a particular layer-decomposition. A coarse decomposition (e.g., a single "AI" defendant abstracted across foundation-model providers, deployers, and infrastructure) collapses doctrinal distinctions that the cases of Part I rely on. The Bommasani et al. assets-and-dependencies framing — which counted 262 assets and 356 dependencies in early 2023 — is the academic operationalization of the granularity claim: the ecosystem actually has many distinct actors at many distinct layers, with documentable dependencies between them. Conway's ruling in Garcia keeping Google in the case as a foundation-model provider while permitting the deployer claims to proceed against Character.AI is a doctrinal operationalization of the same multi-actor, multi-layer ecosystem reality. Treating "AI" as a single homogeneous defendant misframes every interesting doctrinal question. Treating it as a layered ecosystem with documented inter-layer dependencies opens the doctrinal questions to the answers each layer's facts can supply.

§II.3 The seven harm-relevant layers

For purposes of this site's per-layer walks (Part III), we organize the ecosystem into seven harm-relevant layers centered on the harm-and-legal-attribution question. The seven-layer reshape inherits the layered-ecosystem analytical mode from the academic substrate cited at §II.2 (Bommasani 2021 foundation-model downstream-dependency framing; Bommasani et al. 2023 assets-and-dependencies ecosystem-graphs framing) and applies it to a different organizing principle — where in the layered ecosystem can harm originate, where can it be prevented, where can legal-attribution attach. The reshape is descriptive, not prescriptive — courts and litigators will draw their own layer boundaries based on the facts of particular cases. The reshape is intended to make the per-layer walks legible, not to assert that AI's layered structure can only be analyzed this one way.

Layer 1 — Foundation: Training Data and Pre-Training

What goes into the training corpus, before any training has begun: the texts, the conversations, the curation decisions about what to include and what to exclude. This layer is technically distant from the end user but causally upstream of every output the user will eventually see. Pre-training-data curation choices about whether to filter sui­cide-related text from the corpus, whether to include content from clinical contexts, whether to distinguish first-person ideation from third-person discussion, propagate downstream.

Layer 2 — Architecture: Models and Training Methodology

The neural-network architecture (Transformers and their successors), the training methodology (gradient descent over the corpus), and the alignment training that follows pre-training (RLHF, Constitutional AI, RLAIF). This is where the model "learns" what to say and is trained, in stages, toward what humans (the alignment trainers) want it to say. Training-methodology choices affect what the deployed model will produce on what kinds of prompts.

Layer 3 — Frontier Labs: Foundation-Model Production

The labs that build the largest models (Anthropic, OpenAI, Google, Meta, xAI, others). This layer is the most-publicly-visible and the most-litigated. Within Layer 3 sit several functional sub-layers worth distinguishing: red-team practices; safety evaluation and TEVV; alignment-training operations; scaling-policy frameworks (RSPs and equivalents); SB 53 and EU AI Act compliance machinery. Part III walks the sub-layers in detail.

Layer 4 — Application Layer: Deployers and Integrators

Third parties that build products atop frontier-lab APIs. Character Technologies (operator of Character.AI) is the canonical example for our purpose — a deployer whose product runs atop earlier underlying model technology, whose product design choices (chatbot personas; role-play features; content-filter selection; user-onboarding flows) are layered on top of the API access. Other deployers in the consumer-AI space include various integrators and chatbot-product builders. Conway's product-not-speech holding in Garcia opens this layer to direct product-liability framing.

Layer 5 — Hosting and Infrastructure

Cloud providers, content-delivery networks, identity and authentication services. The "plumbing" layer that runs deployed AI products in production. The component-part-manufacturer theory pleaded against Google in Garcia treats this layer as one where liability can attach when the infrastructure provider is also a foundation-model provider whose model technology was used. Pure-infrastructure providers (cloud and CDN providers without model technology participation) are doctrinally distinct, though plaintiffs' attorneys will continue to test where the line falls.

Layer 6 — End-User Surfaces

Chat user-interfaces, mobile apps, embedded chatbots — the surface where AI-generated output reaches a person. UX safety design (crisis-resources offers; method-information detection; conversation-deflection patterns; minor-protection product flags; age-gate design and enforcement) lives here. This is the layer where failure-to-warn doctrine has its sharpest application: what warnings the user-facing surface presents, when, and how, are doctrinally examined directly.

Layer 7 — Cross-Cutting Operations

Trust & Safety operations (content moderation, user reports, account actions); post-deployment monitoring (production telemetry; abuse-pattern detection); policy and communications (transparency reports; public statements; regulatory-affairs liaison); legal and compliance (terms of service; privacy policy; regulatory filings; litigation defense). These functions cut across Layers 3 through 6 — they are not a layer of the technology stack but a layer of the organizational stack. We treat them together because the cross-functional coordination (or lack of coordination) between these operational functions and the technical-and-product layers is itself an analytical surface — the bonus question Q14 (department-counsel coordination gaps) lives here.

The seven layers above are the structure of Part III's walks. Each layer's section in Part III opens at 9th-grade density (what the layer is; what people who work in the layer do; why the layer matters for harm), develops at college-soph density (the technical issues that arise at the layer; the legal issues that intersect with those technical issues), and includes grad-intern callouts (doctrinal nuance; methodological depth; statutory specificity; scholarly debate).

GRAD-INTERN — Why the seven-layer reshape captures the harm-and-attribution geometry

The reshape is not arbitrary. Layer 1 (foundation/data) is the upstream-most layer; harm originating here propagates through every subsequent layer. Layer 2 (architecture/methodology) is where the upstream conditions become deployed-model behavior. Layer 3 (frontier-lab production) is where deployed-model behavior becomes a product (or set of API offerings). Layer 4 (application/deployers) is where product becomes user-facing experience. Layer 5 (hosting) is where user-facing experience runs in production. Layer 6 (end-user surfaces) is where user-facing experience reaches a person. Layer 7 (cross-cutting operations) is the organizational glue across the stack. The geometry maps a physical trace from upstream to downstream — exactly the trace that product-liability and proximate-cause analysis follows when reasoning about where harm originated and who was operating at that point. Conway, in keeping Google in Garcia, was reasoning across Layers 2-5 simultaneously: the model technology (Layer 2) trained at Google (Layer 3) became the substrate Character.AI built atop (Layer 4); Character.AI ran in production presumably on Google Cloud or comparable infrastructure (Layer 5); the chatbot reached the decedent through Character.AI's user-facing app (Layer 6). Every doctrinal move the court made traced the chain. The layered framing is not stylistic; it is the medium of the doctrinal analysis.

§II.3 close — Visual map

The figure organizes the seven layers top-to-bottom by causal flow — from upstream training data (Layer 1) to downstream end-user surfaces (Layer 6) — with Layer 7 Cross-Cutting Operations alongside Layers 3 through 6 as the organizational stack. The reshape is descriptive, not prescriptive: courts and litigators will draw their own layer boundaries on the facts of particular cases. The visual is a supplementary navigational aid; the Part II text alone establishes the seven-layer structure.

Reader-by-need: Part III walks step into each layer in turn; the per-layer walks are the substantive content, with the visual serving as orientation aid when it lands.

Part II forward-pointer

Part II has assembled the layered framing the rest of the site relies on. Part III steps into each of the seven layers in turn, treating the technical-and-legal walk at three densities. Reader-by-need: a reader interested primarily in litigation strategy may skim Part III's per-layer technical openers and dwell on the legal-issues sub-sections; a reader interested in the technical landscape may dwell on the technical openers; a reader new to the entire field will benefit most from reading each layer's 9th-grade opener in sequence and using the sub-section grad-intern callouts as optional deep-dive reference.