Training Data Has a Timeline

California AB 2013 gives training-data transparency a temporal dimension. A developer must describe when data was collected, whether collection is ongoing, and when datasets were first used in development; public availability and later substantial modifications create a separate release timeline. This chapter keeps those clocks apart so readers can tell what a date actually anchors, how OpenAI and xAI describe their histories, and why a model’s training date does not reveal the full composition of its dataset.

Dates matter because training data is not necessarily a closed object. A provider may continue collecting data after a dataset was first used. A model may be trained at one point, fine-tuned later, and made publicly available at another. A substantial update can create another public event even when the provider describes it as a new version or feature release. If those events are compressed into one vague “training date,” the public account becomes easier to misunderstand.

Four clocks, not one

Section 3111 asks for two direct time facts about the datasets: the period during which the data was collected, including notice if collection is ongoing, and the dates the datasets were first used during development. Those are not the same event.

Collection period describes the period during which the data was collected. It can span months or years. Ongoing collection tells the reader that the period has not simply ended at the date of publication. First use in development identifies when the dataset began to participate in developing the system or service. A dataset can be collected in one period and used for development later, or be used while collection continues.

A fourth clock comes from the provider’s own technical description: when a named model was trained. xAI, for example, lists approximate training dates for named Grok versions. Those dates are useful evidence about the model timeline, but they are not automatically the same as the first-use date for every dataset, the end of data collection, or the date of public availability.

A fifth clock matters for the scope of the law: when the system or service is made publicly available to Californians for use. That public-availability event is the trigger described in §3111. It is related to development history, but it is not a synonym for collection or training. The statute’s recurring rule requires the documentation to be posted before each later covered system, service, or substantial modification is made available under the stated conditions.

The distinctions can be summarized without treating them as a rigid universal pipeline:

stateDiagram-v2 [*] --> Collection Collection --> OngoingCollection: Collection continues Collection --> FirstUse: Dataset first used in development OngoingCollection --> FirstUse FirstUse --> ModelTraining: Named model is trained ModelTraining --> PublicRelease: System or service is released PublicRelease --> SubstantialModification: Material functionality or performance change SubstantialModification --> FirstUse: New development cycle

The diagram’s value is causal, not merely chronological. Collection supplies the historical window. First use connects a dataset to development. Training ties development to a named model when the provider reports that fact. Public release creates the external event relevant to the statute. A material modification can send the system through another cycle.