From Source Works to Model Behavior

The technical pipeline behind a generative AI system determines which copyright facts can later be established. This chapter follows the path from source works to curated training data, learned model weights, and deployed behavior. The goal is not to inventory every engineering component, but to understand why data quantity, quality, selection, training phases, memorization, retrieval, and output controls change the legal questions that follow.

The Copyright Office’s report on generative AI training treats this pipeline as more than a preliminary technical detail. Developers make choices about what to collect and what to remove; different actors may train or deploy the same model; and a user-facing product may add retrieval or filters that are absent from the underlying weights. A sound analysis therefore begins by reconstructing what the system actually used and did.

Data is not just a pile of files

Developers generally want training data to satisfy three overlapping requirements: enough quantity to expose the model to many examples, enough quality to make those examples useful, and enough relevance to serve the model’s intended purpose. These goals can conflict. A massive web crawl may provide breadth but also contain errors, navigation elements, watermarks, mislabeled images, and duplicated material. A smaller collection of carefully edited books, academic writing, legal opinions, or high-quality images may offer richer examples but less coverage.

The Copyright Office reports that increasing the quantity of training data has generally improved performance on unseen test data when computing and other conditions do not become bottlenecks. That relationship is not presented as an unlimited law of nature. The marginal value of more data remains an open question, and better test performance does not necessarily translate into the same improvement in real-world usefulness. The report also describes research suggesting that quality can matter more than quantity in some systems. A developer deciding between another billion noisy documents and a smaller, cleaner collection is making a model-design choice, not following a universal recipe.

Purpose narrows the choice further. A system intended for legal work benefits from legal documents; a medical system benefits from medical literature; a multilingual model may need aligned material in several languages; and a general-purpose foundation model seeks a wide range of speech, subject matter, and styles. An image model trained mostly on outdoor photographs may perform less well on indoor scenes, posters, cartoons, or quilt designs. The intended use therefore helps explain why particular categories of expressive work were valuable to the developer. It also creates an important factual question: was a work simply present in a broad collection, or was a category of work deliberately selected because it improved a particular expressive capability?

Acquisition has several meanings

Training material can enter the pipeline through different routes. Developers may use material they own, data supplied through customer or user interactions, licensed collections, third-party databases, public backups, web crawls, or datasets curated by another organization. “Publicly available” is often used to mean that material can be found or downloaded on the internet. It does not, by itself, mean that the material was authorized for AI training.

That distinction is easy to miss because the technical action may look the same. An automated tool can download a page whether the page is openly accessible, governed by a license, behind a subscription barrier, or copied from an unauthorized repository. The resulting file may enter the same storage system, but the source and access path are different facts. The report notes that training collections have included both openly available material and sources alleged to contain pirated books or other illegally accessed works. Those examples do not establish that every developer used those sources. They do establish why a serious inquiry must ask how the developer obtained the work rather than stop at “it was online.”

Acquisition can also involve a chain of intermediaries. One organization may collect web material; another may filter and package it; a model developer may download the package; and a downstream actor may continue training an already released model. A later user may interact with a cloud service without ever seeing the underlying data or weights. Each handoff can affect who possessed a copy, who decided how it would be used, and which records exist to support or contradict a claim.

Curation changes both the dataset and the evidence

Raw data is rarely ready for training. Developers or dataset providers may filter explicit or illegal material, remove watermarked or mislabeled examples, exclude unusually small or redundant files, and deduplicate repeated documents. They may clean text by deleting navigation labels, calls to action, social-media counters, or other fragments that add little training value. They may remove author, title, or copyright information as part of that cleaning, although the legal significance of doing so is a separate question.

They may also compile several collections into one training mix. A dataset can give extra weight to material that helps with a target capability, such as medical knowledge, multilingual performance, long-context reasoning, or instruction following. Weighting means that some examples appear more often in the training process; it can produce duplicates even when the original collections were not duplicated. A developer may also use a pre-existing dataset instead of performing every curation step personally.

These operations matter for two reasons. First, they influence what a model learns. Removing duplicates may reduce repeated exposure to a work; emphasizing a high-quality subset may increase its influence relative to the rest of the corpus; and removing context or metadata may make later attribution harder. Second, each operation can make the pipeline less transparent. The final dataset may not show which original works were collected, which were rejected, how often an item was sampled, or which party made the choice. Absence from the final package is not proof that a work was never acquired, just as presence in a raw crawl does not prove that the work materially shaped a particular model.

A useful reconstruction therefore distinguishes at least four records: what was available to the collector, what was actually downloaded, what survived curation, and what was presented to the model. Those records need not match. A source may be collected and later discarded. A work may be retained but sampled rarely. A subset may be repeatedly sampled because it serves a specific purpose. The technical description is not a legal verdict, but it tells a decision-maker where to look for the facts that a verdict would require.

flowchart LR A["Available source material"] --> B["Acquisition"] B --> C["Filtering and cleaning"] C --> D["Deduplication and weighting"] D --> E["Compiled training mix"] E --> F["Training batches"] F --> G["Updated model weights"] G --> H["Deployed system"] H --> I["RAG, tools, or filters"] I --> J["User-facing behavior"] B -. "what was downloaded" .-> K["Pipeline evidence"] C -. "what survived" .-> K F -. "what was shown" .-> K H -. "who controls access" .-> K

Training produces behavior, not a simple archive

A generative model begins as a mathematical structure whose parameters have not yet learned useful relationships. Training repeatedly exposes it to examples, measures how well it performs, and adjusts the parameters in the direction that improves the chosen objective. The parameters—often called weights—are the numerical values that define how the network maps inputs to outputs.

For a language model, the basic objective is commonly next-token prediction. Text is divided into tokens, which may be words, pieces of words, or punctuation. Given the preceding context, the model estimates what token is likely to come next. It compares that estimate with the token in the training example, then updates its weights. Repeated across many examples, the process can produce a system that generalizes: it responds to new inputs by applying patterns learned from prior examples rather than merely reproducing a stored list.

The same broad logic applies to other media. An image system may learn relationships between text descriptions and image representations; a diffusion system may learn to remove noise from images associated with captions; audio and video systems use their own representations and objectives. The important point is not that every system works identically. It is that source material is used to shape a statistical mapping, and the mapping is later embedded in a model that may be distributed or connected to other software.

Training phases are purposes, not legal labels

Training is usually iterative and may involve several phases. A large initial phase may teach broad language, visual, or audio patterns. Later training may adapt a general model to a narrower domain, improve instruction following, align behavior with human preferences, or strengthen a specific capability. A party may conduct “continued pre-training” on a model that someone else already trained. The terms “pre-training,” “post-training,” and “fine-tuning” are therefore useful descriptions, but they do not tell us by themselves what data was used, why it was used, or how important it was.

This matters when people describe a model as if it had one owner and one training event. A developer may release weights after a first phase, and another organization may build a new system by training those weights on additional material. The second system inherits some behavior from the first, but the later actor has made new choices about data, objectives, and deployment. A claim about “the training data” may need to identify which phase and which model it means.

The same distinction helps explain why a domain-specific model can require different evidence from a general-purpose model. A focused model may be evaluated by what its additional legal, medical, or coding data contributes. A foundation model may rely on broad mixtures whose individual works are difficult to connect to any one capability. Neither situation settles how copyright law applies. It changes what technical and business records would be relevant to the analysis.

Memorization is a spectrum with legal consequences

The goal of generalization does not guarantee that a model will never retain specific material. The Office records disagreement about memorization. Some developers describe weights as numerical relationships or statistical facts rather than copies of the training data. Other commenters point to models that have produced verbatim, near-identical, or substantially similar passages, images, or other expressive material. The report’s careful middle position is that learned patterns can be highly abstract, highly specific, or somewhere in between. When a pattern is highly specific, it may amount to memorized training data.

The extent of memorization can depend on the number of parameters, duplicates in the training set, repeated exposure to the same example, whether the example is unusual, when it appears during training, and how “memorization” is defined. A model that can reproduce a rare passage is different from one that has learned a general fact about language, but the boundary cannot be inferred from the existence of weights alone. The report does not provide a universal memorization rate or a test that resolves every architecture.

This uncertainty has a practical implication. If a model generates a particular work without receiving the relevant expression through a prompt or an external retrieval source, the system’s behavior is evidence that the expression exists in some form within the model. If a system produces a passage only after retrieving it from a database, the evidence points to a deployment event instead. If the output is merely similar in a broad style, the technical and legal questions are different again. The observed behavior, the inputs supplied at generation time, and the system’s architecture must be examined together.

Deployment determines what reaches the user

Users rarely interact with model weights directly. A deployed product can wrap the model in software that changes its inputs and outputs. It may generate search queries, retrieve documents, call external tools, maintain conversation history, rewrite a prompt, or apply safety and copyright-related filters. These additions can make the same underlying model behave differently in two products.

Retrieval-augmented generation, usually called RAG, is especially important. In one design, a developer copies material into a retrieval database and supplies relevant passages to the model when a user asks a question. In another, the system retrieves material from an external search engine or website at request time. The model then receives that material as additional context. A response may summarize the retrieved content, quote it, link to it, or combine it with the model’s prior capabilities. The source of the response is consequently not always the same as the source of the model’s learned behavior.

Deployment can also constrain behavior. An input filter may block a request likely to elicit a protected work. A hidden system instruction may tell the model not to produce certain characters or imitate certain living artists. An output filter may stop a response before it reaches the user. Alignment training may make unwanted behavior less likely. None of these measures is infallible: the line between desired and undesired content is partly subjective, and users may sometimes bypass or degrade a guardrail. Their effectiveness must be assessed in the actual product, not inferred from a policy statement.

Control is distributed in other ways as well. A company may keep a model on its own cloud service and expose it through an application programming interface. Another developer may receive downloadable weights, retrain them, and deploy a new system. A model may run on a phone or other device, where updates and access are controlled differently. “Open” distribution may expand experimentation while making it harder to identify which actor controlled a later use. The technical chain thus becomes an actor chain.

The central lesson is that a model is neither simply a database of its training works nor an unexplained black box that ends the inquiry. The evidence lies in the path: what was acquired, how it was curated, which phase used it, how the weights behave, whether retrieval supplies expression at generation time, and who controls the public-facing system. Those facts do not decide fair use or liability on their own. They make it possible to ask the right legal question at the right stage, rather than treating every use of copyrighted material as technically and legally identical.

References