The Twelve-Part Schema Behind a “High-Level Summary”
California AB 2013 does not ask a developer to place an undifferentiated paragraph about “training data” on a website. It names the first four questions a high-level summary must answer: where the datasets came from, how they serve the system’s intended purpose, how much data they contain, and what kinds of data points they include. This chapter explains how those questions work together so readers can tell a useful summary from a collection of broad but disconnected labels.
The distinction is practical. A provider can say that it used public data, a large corpus, or multimodal information and still leave the reader unable to connect those statements. AB 2013 supplies a structure for making the connection. It does not impose one universal vocabulary for every dataset, and the cited provisions do not prescribe a single template. But they do make clear that provenance, purpose, scale, and composition are different parts of the account.
A high-level summary is structured, not exhaustive
Section 3111 requires documentation on the developer’s internet website regarding data used to train a covered generative-AI system or service. It says the documentation must include a high-level summary of the datasets used in development, followed by specified kinds of information. “High-level” sets the level of description; it does not erase the required subjects.
That combination answers a common misunderstanding. The law does not turn the summary into a demand for every record, URL, prompt, or file in a training corpus, at least not in the cited provisions. But neither does “high-level” mean that a developer can avoid saying anything concrete. A summary should let a reader understand the major origins, role, scale, and character of the data without pretending that a broad category is a complete inventory.
The first four categories are best treated as a chain. Sources or owners identify the data’s provenance. Intended purpose explains its connection to the system. Number of data points supplies a scale estimate. Types of data points describe the data’s composition according to whether it is labeled or unlabeled. If any link is missing, the reader’s understanding becomes less reliable. A source label without a purpose is context-free; a number without a unit or dataset boundary is difficult to interpret; a type description without a source can hide how the composition arose.
Source is not purpose
The first statutory question is: Who supplied the data, or who owns it? Section 3111 asks for the sources or owners of the datasets. That wording can accommodate different kinds of provenance. A developer may describe material by source class, by owner, or by another high-level grouping that tells the reader where the dataset came from. The provision does not, in the text retained here, dictate one naming system or require a record-level catalogue.
The second question is: How do those datasets further the intended purpose of the system or service? This asks for relevance, not merely origin. A source tells us where the material entered the pipeline. A purpose statement tells us why the developer considers that material useful for the system it is building.
Consider the difference between two statements:
- “The system was developed using publicly available data.”
- “Publicly available data was used to help the system model patterns in human language and generate text for its intended uses.”
The first is a provenance statement. The second adds a purpose relationship. It may still be broad, but it explains the proposed connection between the dataset and the product. A careful reader can then ask whether the described purpose matches the system’s actual intended use, rather than treating every source as self-justifying.
OpenAI’s public summary illustrates this paired structure. OpenAI identifies publicly available data, data accessed through third-party partnerships, information provided or generated by users or human trainers and researchers, and synthetic data. It also says data is used to help systems understand human language and the world, enhance human creativity, advance scientific discovery and medical research, and support daily life. The source classes and the stated purposes are related, but they are not the same claim. The page becomes more informative because it supplies both.
xAI uses a similar logic in its disclosure about Grok. It names public Internet data, data produced by third parties for xAI, data from users or contractors, and internally generated data. It connects its use of datasets to goals such as truth-seeking, understanding the nature of the universe, and accelerating scientific discovery. Those are xAI’s own descriptions of intended purpose. They support what xAI says it is trying to accomplish; they do not independently demonstrate that a particular dataset actually advances those goals.
That last distinction matters whenever a summary uses aspirational language. “This data supports scientific discovery” can be a meaningful statement of intended purpose, but it is not the same as evidence that the data improves scientific performance. AB 2013 asks for the relationship the developer claims between data and purpose. It does not, in these provisions, turn that statement into an independent outcome study.
Scale needs a boundary and a unit
The third category asks for the number of data points included in the datasets. The statute permits the number to be expressed in general ranges and allows estimated figures for dynamic datasets. That is a deliberate accommodation: a high-level disclosure can communicate scale without pretending that an evolving dataset has one permanent, exact count.
A range can be more honest than a spurious point estimate. If a dataset changes as new material is collected, processed, or incorporated, the number depends on the date of measurement and the boundary of what is counted. A disclosed estimate can tell readers the order of magnitude while acknowledging that the object is moving. The legal text does not require the reader to confuse a range with a failure of precision; it expressly allows general ranges and dynamic-dataset estimates.
But a number has meaning only when its boundary is clear. Is the figure for raw collected material, filtered data, data actually used in development, or several datasets combined? Does it cover one modality or many? Does it refer to a static snapshot or an ongoing collection? The cited provisions do not supply a universal counting methodology, so a reader should not silently fill in those details.
Tokens make this issue visible. OpenAI reports datasets containing trillions of tokens of textual, image, audio, and audiovisual content. xAI reports datasets and dynamic datasets containing trillions to tens of trillions of tokens. Those statements communicate enormous scale, but “token” and “data point” are not automatically interchangeable units. A token can be one unit in a representation of text; a data point can refer to an item in a dataset. The cited sources do not establish a shared conversion, counting boundary, or comparison method.
The correct reading is therefore attributed and modest: OpenAI reports a token-scale figure across several kinds of content, and xAI reports a token range that includes dynamic datasets. A reader may conclude that both providers describe development at very large scale. A reader may not derive a reliable ranking from the two numbers alone. The documents do not tell us that they count the same things in the same way.
This is also why dynamic datasets deserve special attention. If collection is ongoing, a published number can age without becoming deliberately misleading. The relevant question is whether the summary signals that the dataset is dynamic and whether the estimate is presented as an estimate. The statute’s wording recognizes that the public needs a useful scale description even when the underlying quantity changes.
A strong scale statement should therefore answer three linked questions, even at a high level: what is being counted, in what unit, and over what boundary or time? The law expressly permits general ranges, but it does not make unexplained numbers informative merely because they are large.
“Types of data points” changes with the dataset
The fourth category avoids treating all datasets as if they have the same internal structure. Section 3111 says that for datasets that include labels, the types of data points mean the types of labels used. For datasets without labeling, “types of data points” refers to general characteristics.
A label is an assigned description or category attached to an item. Imagine a dataset in which examples are paired with labels indicating a content category, a language, or a task outcome. In that setting, describing the label types tells the reader how the data has been organized for development. The relevant question is not only whether the items are text, images, or audio. It is also what distinctions have been applied to them.
An unlabeled dataset presents a different problem. If there are no assigned labels, the summary cannot accurately describe “types” as though a hidden annotation scheme exists. The statute instead points to general characteristics. Those characteristics might include broad modality, format, or other high-level features that genuinely describe the dataset. The point is not to force every corpus into a labeled-data vocabulary.
This distinction also limits what a short provider statement can establish. OpenAI’s references to textual, image, audio, and audiovisual content provide broad modality information. They are useful general characteristics, but they do not expose every label or internal classification that may exist in particular datasets. xAI’s source-recipe description identifies where several classes of data came from and how several development stages were used; it does not, by itself, enumerate every characteristic or label.
Absence from a concise summary should not be overread. If a public page names broad modalities but does not display an internal annotation taxonomy, the evidence supports the claim that the page names those modalities. It does not support the stronger claim that no other labels or characteristics exist. The difference is between an unreported detail and evidence that the detail is absent.
The labels-versus-characteristics rule also explains why a universal checklist can mislead. For one dataset, the most informative description may concern annotation categories. For another, the important facts may be modality, format, or broad source characteristics. The statutory category stays stable while the appropriate description changes with the data’s structure.
Reading the four categories as one argument
The first four fields are not four chances to repeat the same sentence. They answer four different parts of a causal argument about development data:
- Origin: where the data came from or who owns it.
- Relevance: how the developer says it furthers the system’s intended purpose.
- Scale: how much data is included, with a range or estimate where appropriate.
- Composition: what kinds of data points or labels, or what general characteristics, are present.
Suppose a provider says that it used public Internet data in a very large dataset to build a system that generates language. A reader can now ask: Which kinds of public Internet sources? How does the provider connect them to the intended purpose? Is the scale a data-point count, a token estimate, or another measure? If the data is labeled, what labels are being described; if not, what characteristics define it? These are not demands for a raw corpus. They are questions the statutory schema makes possible.
The schema also helps identify weak explanations without automatically declaring noncompliance. A source statement may be broad because the developer is summarizing many datasets. A range may be appropriate because a collection is dynamic. A modality description may be all that is meaningful for an unlabeled dataset. The reader should record what the statement supports, preserve its qualifiers, and note what remains unclear before drawing a conclusion.
The most useful summary is therefore not the one with the most impressive number or the longest list of source names. It is the one that lets a reader connect origin to purpose, scale to a stated unit and boundary, and composition to the dataset’s actual structure. The remaining statutory categories add rights, privacy, processing, synthetic-data use, and time. Those categories matter precisely because the first four do not tell the whole story. A dataset can be well described by source and scale while still leaving important questions about legal status, sensitive information, transformation, or history unanswered.
Once the basic schema is clear, public provider pages can be read as evidence rather than as marketing shorthand. The next step is to apply these four questions to OpenAI and xAI side by side, preserving what each provider says and refusing to manufacture a common measurement system where the sources do not provide one.