AI Harm Landscape

independent research compilation

Part III-a

Layers 1-3

§III.1 Layer 1 — Foundation: Training Data and Pre-Training

What this layer is, in plain language

Before any AI model can produce output — before a chatbot can write back to a user — the model must be trained. Training is the process of giving the model billions or trillions of examples of human language (and, in some cases, other media) and adjusting the model's internal numerical parameters so it learns to produce statistically reasonable continuations of any input it sees. The collection of examples used for training is called the training corpus. The decisions made about what to include in the corpus, what to exclude, and how to filter or weight the included material — those decisions are made at the foundation layer, before training happens.

People who work at this layer include data engineers, dataset curators, alignment-data specialists, content-classifier engineers, and researchers who study what training corpora contain and how their composition affects downstream model behavior.

Why this layer matters for harm output

The training corpus is causally upstream of every output the model will eventually produce. If a model has been trained on a corpus that contains substantial first-person discussion of suicide methods, or extended fiction romanticizing suicide, or clinical discussions of self-harm without protective framing, the model will (in general, and with the limits of statistical learning) be more likely to produce that kind of content when prompted. If the corpus has been curated to exclude or reweight such content — or if the corpus has been augmented with protective content (crisis-resources information; clinically-grounded self-harm-reduction language) — the model's deployed behavior will reflect those upstream choices.

Pre-training data curation is therefore one of the most consequential — and least visible — harm-prevention surfaces in the AI ecosystem. The choices made here propagate through every downstream layer. A model whose training corpus included substantial method-specific suicide content will, at deployment, require more aggressive downstream safeguards (alignment training; content filters; user-interface mitigations) to suppress that content from reaching users than a model whose training corpus was curated to exclude or reweight such content from the start.

Technical issues at this layer

The technical practice of training-data curation includes:

Legal issues at this layer

Pre-training has several distinct legal-issue clusters:

GRAD-INTERN — Pre-training data curation is the harm-prevention surface Horn underweights, and the surface where research substrate is currently thinnest

Andreas Horn's ten-layer ladder, discussed at Part II, omits pre-training data curation entirely. The omission is not Horn's failure; his framing was built for a different purpose. But the omission is consequential for our project. Pre-training is upstream of everything else in this site's harm-analysis: every alignment-training choice, every red-team finding, every deployed-product behavior is conditioned on what the model was trained on. And — to be straightforward about the state of our research — this is the layer where our R1 research corpus is thinnest. We have substantial substrate on red-team practices (covered at §III.3.a below), on safety evaluation (§III.3.b), and on lab safety policy (§III.3.d). We have less substrate on the upstream decisions about what enters the training corpus and how it is filtered. The labs do publish some material on this (corpus assembly is touched in foundation-model technical reports, including OpenAI's GPT-4 system card and Anthropic's transparency-related publications), but the public-facing material is significantly less detailed than the public-facing material on red-teaming or alignment training. Specific gaps include: (a) per-lab pre-training-data-curation methodologies for harmful-content categories, with detail at the level of "what content categories are filtered, by what method"; (b) the role of suicide-related content in pre-training corpora and the labs' public-facing positions on its inclusion or exclusion; (c) academic and industry analysis of the downstream effects of pre-training-data curation on harm-output rates. We mark these as candidates for follow-on research; the present analysis treats Layer 1 as a layer that exists doctrinally and operationally without claiming substrate-rich analysis at the verbatim-pin granularity we provide for §III.3.

§III.2 Layer 2 — Architecture: Models and Training Methodology

What this layer is, in plain language

Layer 2 is the methodology of training itself: how the model learns from the training corpus, and what additional shaping is applied to the model after the basic pre-training is complete. The neural-network architecture (Transformers and their successors) supplies the structure; the training methodology supplies the learning process; the alignment training supplies the post-pre-training shaping that determines what the model will (and will not) say in response to user prompts.

People who work at this layer include alignment researchers, RLHF (reinforcement-learning-from-human-feedback) engineers, Constitutional-AI specialists, training-pipeline engineers, and the human contractors who provide preference labels that drive alignment training.

Why this layer matters for harm output

After pre-training, a foundation model can produce statistically reasonable continuations of inputs — but that does not mean its outputs are useful or safe for any specific deployment context. Alignment training is the layer where the lab shapes the model's deployed behavior: what it will produce in response to certain prompts, what it will refuse to produce, what it will produce only with caveats or warnings, and what it will produce only after asking for additional context.

For harm-output-prevention purposes, alignment training is where the lab decides — concretely, in trainable form — how the deployed model should respond when a user discusses suicidal ideation, when a user requests method-specific information, when a user is identified or inferred to be a minor, when a user appears in distress. The choices made at this layer become the deployed model's behavior at every downstream surface. The Raine amended-complaint allegation that OpenAI removed safeguards before the decedent's death is, technically, an allegation that some change at this layer (or at downstream policy-and-config layers tightly coupled to it) produced a less-protective deployed behavior.

Technical issues at this layer

The principal alignment-training methodologies in current use across the major labs are:

Each methodology has trade-offs in terms of (a) the kinds of behaviors it can effectively shape, (b) how quickly behaviors can be re-shaped after deployment when problems are identified, (c) how transparently the methodology can be described to outside reviewers, (d) the scalability cost. The labs publish varying amounts of detail on their internal alignment-training practice; substrate-richness varies widely across labs.

Legal issues at this layer

The legal touchpoints at Layer 2 include:

Where the substrate is dense (and where it is not)

Anthropic, in a 2024 publication titled "Challenges in red teaming AI systems," provides verbatim description of how the lab applies adversarial testing to deployed models. The publication describes, in the lab's own words, that "Red teaming is a critical tool for improving the safety and security of AI systems. It involves adversarially testing a technological system to identify potential vulnerabilities." (Source: https://www.anthropic.com/news/challenges-in-red-teaming-ai-systems , published June 12, 2024.) The same publication notes a significant industry-level gap: "The lack of standardized practices for AI red teaming further complicates the situation. Developers might use different techniques to assess the same type of threat model, and even when they use the same technique, the way they go about red teaming might look quite different in practice." This is itself a doctrinally consequential observation: where industry standards do not exist, standard-of-care analysis in subsequent litigation becomes harder to ground.

Substrate on RLHF and Constitutional AI mechanics in the depth needed for litigation-style cross-examination is more dispersed. Anthropic and OpenAI have published methodological papers; substantial academic literature exists. Our R1 research corpus contains primarily lab-publication-level substrate; per-method litigation-grade detail is a candidate for follow-on research.

GRAD-INTERN — Constitutional AI as a doctrinally distinctive methodology

Anthropic's Constitutional AI methodology is doctrinally distinctive because it makes the lab's alignment-training criteria explicit and written in a way that makes them more accessible to litigation discovery than methodologies whose criteria live primarily in human-contractor preference labels. A "constitution" — the written set of principles against which the model is trained to critique itself — is a documentary artifact that, in subsequent litigation, becomes a clear evidentiary target. Plaintiffs in failure-to-warn or negligent-design matters will examine the constitution's content with respect to harm-output categories: did the constitution include explicit principles bearing on suicide-related conversation; did its principles change over the deployment period; did changes affect deployed-model behavior on the categories of conversation the harms in question implicated. Methodologies that rest primarily on dispersed human preference labels are factually harder to characterize in litigation but, structurally, are not less reachable in discovery — preference-label sets are documentary artifacts too. The doctrinal frontier here is whether courts will accept the framing that alignment-training methodology is part of the product design the design-defect framework examines. As of access date for this research, no published opinion has decided the question at this granularity. Note also that this analysis is descriptive, not prescriptive: we do not assert that any lab's specific methodology is or is not consistent with any standard of care; that determination is a matter for the trier of fact in each specific case, with the actual record of that case before it.

§III.3 Layer 3 — Frontier Labs: Foundation-Model Production

What this layer is, in plain language

The frontier labs are the small set of companies that build the largest models — the foundation models on which most deployed consumer-AI products run. As of access date 2026-05-06, the publicly-most-visible frontier labs are Anthropic, OpenAI, Google DeepMind, Meta AI, and xAI; several others operate at varying scales of capability and visibility. The frontier labs are the layer where the largest internal-organizational infrastructure for AI safety practice lives — where red-team practices, safety evaluation, alignment training operations, and scaling-policy frameworks are operated as ongoing organizational functions rather than one-off engineering tasks.

People who work at this layer include foundation-model researchers, safety-engineering teams, red-team operations staff (in-house and contractor), safety-evaluation teams, alignment researchers (with overlap into Layer 2), and the cross-functional Trust & Safety / Policy / Legal / Communications functions that operate across the lab.

Why this layer matters for harm output

Layer 3 is where the operational practices that determine deployed-product behavior live. The lab's red-team practice determines what classes of harmful output are detected before deployment. The safety-evaluation regime determines what is reviewed at all. The alignment-training operations determine how the deployed model is shaped (with reach back into Layer 2). The scaling-policy framework determines what capabilities the lab is willing to deploy and under what mitigations.

The active wrongful-death matters described in Part I almost always reach Layer 3 in their pleadings — naming the lab's safety practice, or its absence, as the operational source of the harm. Where the Raine amended complaint alleges that OpenAI removed safeguards, it is alleging Layer-3 operational conduct (an alignment-training change; a safety-evaluation gap; a policy-decision sequence). Where the Garcia complaint alleged that Character Technologies deployed a chatbot product with foreseeably-harmful persona behavior atop foundation-model technology from Google, it was alleging Layer-3-and-Layer-4 operational conduct (the foundation-model lab's practices, and the deployer's practices that built atop them).

We treat Layer 3 in four sub-layers: Red-Team Practices (§III.3.a); Safety Evaluation and TEVV (§III.3.b); Alignment Training Operations (§III.3.c); and Scaling Policies (§III.3.d).

§III.3.a Red-Team Practices

Red-teaming is the practice of adversarially testing an AI model — having a person or another AI deliberately attempt to elicit harmful, prohibited, or unintended behaviors from the model, in order to detect such behaviors before deployment and inform mitigations. The U.S. Cybersecurity and Infrastructure Security Agency (CISA), in a 2024 publication, defines AI red-teaming as "the third-party safety and security evaluation of AI systems; AI red teaming is a subset of AI Testing, Evaluation, Verification and Validation (TEVV)." (Source: https://www.cisa.gov/news-events/news/ai-red-teaming-applying-software-tevv-ai-evaluations , published November 26, 2024, by Jonathan Spring and Divjot Singh Bawa.) CISA further notes that the practice is grounded in a longer history: "TEVV has been used for more than four decades to improve the safety and security of software."

Anthropic's published account of its own red-teaming practice, "Challenges in red teaming AI systems," describes a structured taxonomy of red-teaming methods. The lab identifies domain-specific expert red teaming (collaboration with subject-matter experts — including, for example, "Thorn on issues of child safety, Institute for Strategic Dialogue on election integrity, Global Project Against Hate and Extremism on radicalization"), frontier threats red teaming (focused on Chemical, Biological, Radiological, and Nuclear risks; cybersecurity; and autonomous AI risks), region-specific multilingual and multicultural red teaming, automated red teaming using language models against language models, multimodal red teaming, crowdsourced red teaming, and community red teaming via venues such as DEF CON's AI Village. (Source: same Anthropic URL above.)

Anthropic's account also offers the lab's own assessment of an industry-level gap: "The lack of standardized practices for AI red teaming further complicates the situation. Developers might use different techniques to assess the same type of threat model, and even when they use the same technique, the way they go about red teaming might look quite different in practice. This inconsistency makes it challenging to objectively compare the relative safety of different AI systems." This admission — that standardization is absent — has direct doctrinal consequences for any standard-of-care analysis attempting to assess whether a particular lab's red-teaming practice met an industry baseline at the time of a deployment decision implicated in litigation.

CISA's TEVV-framing publication notes that "AI red teaming is a foundational component of the safety and security evaluations process" and argues that AI red-teaming should be operated as a sub-component of broader software TEVV regimes, drawing on "more than four decades" of accumulated software-evaluation methodology. This is an important framing for the doctrinal analysis at §IV.5: voluntary-standard adoption (NIST AI RMF; CISA TEVV) is admissible as evidence of industry standard of care, and CISA's positioning frames AI red-teaming inside the established TEVV regime in a way that carries doctrinal weight.

OpenAI has also published a paper on the lab's external red-teaming approach (titled "OpenAI's approach to external red teaming"); the paper was harvest-deferred during our R1 cycle but is in our research-corpus inventory. Its full verbatim citation is on file in the pinned corpus.

GRAD-INTERN — Why "the lack of standardization" matters for failure-to-warn doctrine

Standard-of-care analysis in tort doctrine asks what a reasonable lab in the defendant's position would have done with respect to red-teaming the deployed product. Industry-wide red-teaming standardization would, ordinarily, supply the reference-point: a defendant's practice is compared to the industry-standard practice and judged accordingly. Anthropic's own published acknowledgment that such standardization does not exist changes the analytical structure. Plaintiffs cannot point to a single "industry-standard red-teaming protocol" against which to measure a defendant's practice; defendants cannot point to such a protocol to argue conformity. Both sides will instead attempt to construct a standard-of-care frame from (a) NIST AI RMF and CISA TEVV (voluntary-standard documents on the way standardization is moving), (b) per-lab published practice descriptions (each lab's own statements about its red-teaming approach), and (c) academic literature on red-teaming methodology. Expert testimony at trial — and Daubert contests around such testimony — will turn on the experts' qualifications to opine about an unstandardized practice. This is one specific reason the AI red-teaming corner of failure-to-warn doctrine is at the threshold rather than at the appellate-development stage as of access date for this research.

§III.3.b Safety Evaluation / TEVV

Safety evaluation is the broader regime within which red-teaming sits. CISA's framing of TEVV — Testing, Evaluation, Validation, and Verification — situates AI safety evaluation as "a sub-component of the more established software TEVV", with "three components: software system test and evaluation process, software verification, and software validation." (Source: same CISA URL above.)

The U.S. National Institute of Standards and Technology (NIST) has operationalized AI TEVV through programs identified by CISA as "Assessing Risks and Impacts of AI (ARIA) and the NIST GenAI Challenge." NIST's voluntary AI Risk Management Framework (AI RMF) supplies the cross-industry reference standard; the labs' adoption of NIST AI RMF — and, where they exist, signatory commitments — supplies (per §IV.5) the standard-of-care evidentiary base for subsequent litigation.

Anthropic, in a series of published frameworks, has positioned its safety evaluation work in alignment with the NIST RMF baseline. The lab's Responsible Scaling Policy (RSP) — discussed in detail at §III.3.d below — operates as the lab's articulated standard for what safety evaluations must occur at what capability levels and to what conclusions. OpenAI publishes safety-evaluation summaries in its system cards (the GPT-4 system card is a representative example pinned in our R1 corpus). Other frontier labs publish varying amounts.

The METR organization (Model Evaluation and Threat Research) supplies a third-party-evaluation analytical layer — describing what frontier labs are doing, what their safety policies say in detail, and where the patterns converge or diverge. METR's most-densely-pinned source in our R1 corpus is at https://metr.org/common-elements (the page on common elements of frontier AI safety policies); a second METR source (https://metr.org/notes/2026-01-29-frontier-ai-safety-regulations/ ) treats frontier-AI safety regulations specifically. METR's framing helps independent observers identify which lab practices are convergent across labs (and therefore plausible candidates for industry-standard recognition) and which are lab-specific outliers. (Full verbatim pulls from METR's primary sources are on file in the pinned corpus.)

The doctrinal significance of safety-evaluation and TEVV practice is twofold. First, the lab's pre-deployment safety-evaluation record is a discovery target in subsequent litigation: what was tested, what was found, what was changed, what was not changed and why. Second, the lab's claimed conformity (or non-conformity) to NIST AI RMF and CISA TEVV creates evidentiary positions in standard-of-care disputes. Where the lab claims conformity in public-facing statements (transparency reports; safety-policy publications; SB 53 compliance attestations), those public claims are admissible as evidence — the lab cannot easily disclaim them in subsequent litigation.

GRAD-INTERN — The discovery surface at safety-evaluation depth

A safety-evaluation regime — pre-deployment red-team reports; capability evaluations; alignment-eval transcripts; post-deployment monitoring reports — produces a substantial documentary record. The labs' standard practice is to treat much of this record as confidential and, where claims of trade-secret protection are asserted, as privileged. Discovery contests in pending matters (especially Raine, with its safeguard-removal allegation) will probe how far that confidentiality / trade-secret protection extends and what balance courts strike with plaintiffs' need-for-disclosure interests. Protective orders are likely; the scope of those protective orders — whether the documents are produced for attorneys'-eyes-only review, or under a more restrictive regime, or under tiered access — will be litigated in each matter. The doctrinal residue of these motion practices, accumulated across several active matters over the next eighteen-to-thirty-six months, will form the discovery-scope frontier for AI-safety-eval documentation. As of access date for this research, no appellate-level ruling on this scope question has emerged in our corpus.

§III.3.c Alignment Training Operations

Alignment-training operations is the cross-cutting function within frontier labs that takes the methodologies described at Layer 2 (RLHF, Constitutional AI, RLAIF, etc.) and operationalizes them: managing the human-contractor pipelines that produce preference labels, building the reward models, running the reinforcement-learning training jobs, evaluating the post-alignment behavior, and iterating. The team or teams responsible for alignment training overlap with research teams that develop new methodologies and with safety-evaluation teams that test the alignment-training outputs.

The lab-specific alignment-training operations are documented in published research papers (Anthropic's Constitutional AI paper; OpenAI's RLHF papers; subsequent technical follow-ups across labs) and in lab transparency-report and safety-policy publications. Substrate at the level of operational specifics (preference-label volume; contractor-pool composition; preference-data quality assurance; reward-model evaluation methodology) is generally less detailed in public-facing material than alignment-methodology research is.

Doctrinal touchpoints at this sub-layer include:

Substrate-richness at the level needed for litigation cross-examination is the substantive challenge here. The labs publish enough to establish that alignment training is happening; the operational specifics that any plaintiff's expert would need to opine about reasonableness are typically not in public materials. Discovery in pending matters will be the principal mechanism by which that detail becomes available — either as public-record material (in motions; in expert reports; in trial testimony) or as protective-order-bound material reachable only to attorneys' eyes. Either way, the doctrinal development of this sub-layer will accelerate as pending matters reach the discovery stage.

GRAD-INTERN — Alignment-training operations as the operational chokepoint where harm-output prevention is decided

Pre-training (Layer 1) produces a model whose statistical behavior reflects the corpus. Architecture (Layer 2) supplies the methodology by which the model can be re-shaped after pre-training. Alignment-training operations is where the lab actually does the re-shaping for deployment — concretely, day-to-day, with operational decisions about what labels to gather, what reward signals to optimize against, what behaviors to preserve, what behaviors to suppress. If a deployed model produces harmful output that pre-training and architecture made possible, alignment-training operations is the layer that decided whether that output was suppressed in deployment. The doctrinal question — whether the alignment-training operations team's decisions about what to suppress were reasonable in light of foreseeable harm — is precisely the question failure-to-warn and negligent-design doctrine is structured to ask. The factual record needed to ground the legal analysis is, at present, predominantly internal to the labs. The litigation pipeline is the principal mechanism by which it becomes externally examinable.

§III.3.d Scaling Policies

A scaling policy — most prominently, Anthropic's Responsible Scaling Policy (RSP), and analogous frameworks at other labs — is the lab's articulated framework for what capability levels the lab is willing to develop and deploy under what mitigations. The RSP is structured around capability thresholds (often called "AI Safety Levels" or similar) and corresponding required mitigations (red-team intensity; safety-evaluation rigor; deployment-restriction; transparency obligations). Anthropic published RSP v3.0 in February 2026; a roadmap of subsequent updates and an ongoing updates page live at the lab's public website. (Sources: https://www.anthropic.com/news/responsible-scaling-policy-v3 ; https://www.anthropic.com/responsible-scaling-policy/roadmap ; https://www.anthropic.com/responsible-scaling-policy/updates — pinned in R1 corpus; full verbatim pulls are on file in the pinned corpus.)

OpenAI maintains an analogous framework, sometimes referred to as a Preparedness Framework (terminology varies; the underlying structure is similar — capability thresholds plus corresponding mitigations). Other frontier labs have published analogous documents in 2025-2026 with varying levels of specificity. METR's work documents the convergence and divergence patterns across these frameworks.

Anthropic's own 2024 publication on red-teaming — which we have quoted above at §III.3.a — closes with policy recommendations to governments, including: "Encourage AI companies to tie their red teaming practices to clear policies on the conditions they must meet to continue scaling the development and/or release of new models (e.g., the adoption of commitments such as a Responsible Scaling Policy)." (Source: same Anthropic URL.) This is the lab's own externalized framing of why scaling-policy frameworks matter: they tie the operational practice (red-teaming; safety evaluation) to deployment-decision criteria (whether to release; under what mitigations).

California's SB 53 — discussed at §IV.4.c — supplies state-level statutory foundation for the kinds of safety obligations that voluntary RSP frameworks had previously articulated. Anthropic published a compliance framework specifically for SB 53 (https://www.anthropic.com/news/compliance-framework-SB53 ; pinned in R1 corpus). The interaction between voluntary RSP frameworks and statutory obligations is a doctrinal frontier: where statutory obligations parallel the lab's prior voluntary commitments, the labs' compliance posture may be shaped by both — and inconsistencies between voluntary and statutory regimes become litigation-relevant.

The doctrinal significance of scaling-policy frameworks is that they create self-imposed standards against which the labs can be measured. A lab that publishes an RSP committing to specific safety-evaluation actions at specific capability thresholds — and then deploys a product without those actions — has made publicly admissible statements that subsequent plaintiffs can cite as standard-of-care evidence. Conversely, a lab that conforms to its published RSP can cite that conformity in its own defense. The voluntary-standard-evidence framework discussed at §IV.5 applies to RSP frameworks the same way it applies to NIST AI RMF.

GRAD-INTERN — RSP frameworks as evidentiary positioning, not (only) safety practice

RSP frameworks have at least three distinct functions. First, they are an internal organizational mechanism: they tell the lab's own teams what is required at what capability level, providing operational clarity. Second, they are a signaling mechanism to industry, regulators, and customers: they tell external observers what the lab is committing to, supporting trust-building and competitive differentiation. Third, they are an evidentiary positioning mechanism: they create publicly admissible statements that bind the lab in subsequent litigation. The third function is doctrinally consequential and is sometimes underweighted in industry commentary that focuses on the first two. A lab whose published RSP commits it to Action X at capability threshold Y, and which deploys a product at threshold Y without Action X, has supplied plaintiffs with evidence of below-self-stated-standard practice — the kind of evidence juries find compelling. A lab whose RSP is vague enough to avoid such commitment provides less evidentiary positioning and less external trust-signaling. The RSP-drafting tradeoff between commitment-specificity (more trust-signaling, more litigation-evidence) and commitment-vagueness (less of both) is itself a doctrinal-strategic choice that becomes visible in subsequent litigation. SB 53 and analogous state-level statutory regimes change this calculus by requiring certain commitments — so the labs no longer have the choice to remain vague on the points the statutes touch.

Part III (Layers 1-3) forward-pointer

Layers 1-3 have walked the upstream-and-foundation portion of the AI ecosystem: where the model's training material is curated; where the model's training methodology shapes its deployed behavior; and where the frontier labs operate the institutional safety practice that determines what is deployed and how.

The remaining four layers — covered in the next composition session per the masterplan's multi-session pattern for Part III — step into the downstream-and-operational portion of the ecosystem: Layer 4 (Application: Deployers and Integrators), where third parties build products atop the foundation-model APIs; Layer 5 (Hosting and Infrastructure), where deployed products run in production; Layer 6 (End-User Surfaces), where AI-generated output reaches a person; and Layer 7 (Cross-Cutting Operations), where Trust & Safety, post-deployment monitoring, policy and communications, and legal and compliance functions cut across the technical stack.

The doctrinal questions developed at Layers 1-3 — design-defect framing; alignment-training-as-product-attribute; the discovery surface around safety-evaluation documentation; standard-of-care analysis in the absence of industry-standardization — carry forward into Layers 4-7. The cases of Part I and the doctrinal frame of Part IV will, by Layers 4-7's close, have all of their layer-specific anchoring laid out.