An AI Bill of Materials Describes an AI System
An AI Bill of Materials (AIBOM) is useful only if it describes the relationships that make an AI system behave as it does. This chapter focuses on those relationships: how data, model artefacts, software, hardware, people, and deployment context fit together, and how a reader can use that map to judge what is known about a system being reused. The goal is not to memorise a longer list of fields, but to learn where provenance comes from, who owns it, and which missing connection can change the meaning of an otherwise familiar model.
The model file remains important. It is simply not the whole subject. When a pretrained model moves into an application, its origin, training data, runtime configuration, surrounding libraries, hardware, and operating controls become part of the object that downstream users must understand. The AIBOM's distinctive contribution is to make those dependencies visible as a connected system.
Six questions, not six boxes
The conceptual framework in the Frontiers study divides the AI system into six domains: data components, model components, software components, hardware components, human and organisational components, and deployment and operational components. The division is useful because each domain answers a different question. It is not a claim that every implementation must use exactly this taxonomy; the paper presents it as a way to make a complex system legible.
Data components answer: what shaped the model and its evaluation? Training data is the obvious starting point, but validation and test data matter too. Their versions, transformations, sampling choices, annotation practices, access conditions, and known bias or quality concerns can affect what a model learns and how its performance is interpreted. If a model is retrained, the relevant data relationship changes even if the model's public name does not. A reference to the dataset therefore does more than point to an input. It gives an auditor a way to ask whether two model releases were built from equivalent sources and whether a later result can be compared with an earlier one.
That relationship also explains why data provenance belongs in an AIBOM rather than in a separate, easily forgotten catalogue. A model may have a stable file hash while the data that shaped it remains unclear. The hash can identify which file was used; it cannot explain the statistical history embedded in that file. Dataset identifiers, version hashes, transformation records, and permitted-use conditions help connect the model to that history. In a sensitive setting, those references can be verifiable without placing the underlying records inside the bill.
Model components answer: which artefact is this, and how was it formed? An AIBOM can identify a model's architecture, version, parameters, training details, and exact serialised artefact. This matters when several files have similar names, when a model is exported into another representation, or when a downstream team needs to establish that the model it evaluated is the one it later deployed. The proposed schema uses a model reference based on a cryptographic hash for this purpose. The hash is an identity anchor, not a description of the model's quality.
Model identity also has a temporal dimension. A model can be fine-tuned, quantised, retrained, or combined with another component. Treating all of those states as one named object hides changes that may matter to reproducibility and risk assessment. The AIBOM approach instead treats model state as something that must be captured and related to a particular execution. This is a more precise question than “Which model family is this?” It asks which artefact, in which state, was involved in the result under review.
Software components answer: what code and runtime substrate made the execution possible? Frameworks, preprocessing code, libraries, operating-system packages, containers, and orchestration tools can all influence the path from input to output. An ordinary software inventory remains valuable here: it can enumerate packages and support vulnerability analysis. The AIBOM adds the relationships that matter specifically for AI, such as which model was loaded, which preprocessing steps were applied, and which container or environment supplied the runtime.
Hardware components answer: where did the computation occur? Development and inference hardware may differ. A CPU, GPU, or other accelerator can be paired with different precision modes, quantisation settings, or device-specific libraries. The important point is not that hardware automatically changes a model's behaviour, but that execution context can change reproducibility, performance, and the interpretation of a claimed result. Recording the device and relevant numerical configuration lets a later user determine whether two executions were genuinely comparable or merely used the same model name.
Human and organisational components answer: who made the system possible and who is accountable for it? The framework includes developers, domain experts, ethical review bodies, and governance documentation. These are not decorative credits. A dataset access condition may have an owner; a limitation may require domain expertise to interpret; a retraining decision may need review; and an output policy may belong to an institution rather than to the model's author. Connecting those roles to the technical record clarifies where decisions are made and where responsibility should be sought when the evidence is incomplete.
Deployment and operational components answer: how does the system live and change? An AI system can be deployed behind a service interface, at the edge, or inside a research workflow. Its operators may monitor model drift or bias, patch dependencies, retrain the model, and respond to incidents. Those activities can change the system without producing a new model family or an obvious package update. An AIBOM that includes deployment topology and operational events makes those transitions part of provenance instead of treating release as the end of the story.
The domains become most useful at their interfaces. If a model hash is recorded without a relationship to its training-data reference, the record identifies the file but not the origin of its learned behaviour. If a container is listed without the model and inference context loaded inside it, the record identifies an environment without proving which workload it hosted. If a deployment is recorded without its monitoring or retraining history, a reviewer cannot easily tell whether a familiar release name still denotes the state that was evaluated. Each example is a different kind of gap, and each calls for different evidence.
The audience for the evidence can differ as well. A model publisher may need to expose identity, licensing, intended use, and limitations. A deployment team may need the execution fingerprint and operational changes. A governance reviewer may need access conditions, review records, and disclosure controls. An AIBOM does not require every detail to be public; it requires the provenance relationship and its visibility rules to be explicit enough that an authorised reviewer can follow it. That is a stronger design than either publishing everything indiscriminately or leaving every boundary implicit.
Taken together, the six domains replace a narrow question—“What files are in this release?”—with a system question: “What combination of data, artefacts, code, machines, decisions, and operations produced this behaviour?” That is the scope an AIBOM must make inspectable.
The domains also differ in what kind of thing they represent. A model file and a container image are artefacts; a dataset access condition is a constraint; a GPU configuration is execution state; a review board is an accountable institution; and retraining is a transition over time. Putting all of them into one undifferentiated inventory would preserve names while losing meaning. The AIBOM becomes informative when it records the type of relationship: a dataset shaped a model, a software environment loaded it, a device executed it, an organisation approved a use, or an operational event replaced one state with another.
Ownership follows those relationships. A model publisher may be able to identify an artefact and describe its intended use without controlling the data on which it was trained. A data steward may control access to the source while not knowing how a downstream team configured inference. A deployment operator may know the container and hardware but not the limitations documented by the original publisher. The six-domain model does not make these parties interchangeable; it gives a provenance record places where their evidence and responsibilities can meet. A missing connection can therefore be an ownership gap, not merely a missing field.
This matters especially when an AI system is assembled from reusable parts. A downstream application may obtain a pretrained model from a public hub, apply local preprocessing, place it in a container, and expose it through a service. Each step can preserve the model's identity while changing the system's operational context. The AIBOM's task is not to claim that every difference produces a different model. It is to retain enough context to tell whether the assembled system is the one that was evaluated, whether the data-use conditions still apply, and which party can answer an unresolved question.
The relationships are the point
A domain model becomes useful when it explains what crosses an interface. Data flows through preprocessing into training and evaluation. A model artefact is loaded by software in a particular environment. Hardware and numerical configuration constrain the execution. The resulting output is subject to disclosure or release controls. People and organisations own the decisions at those boundaries. The AIBOM records enough of these relationships for another party to check whether the story is coherent.
Consider a model that is identified correctly but run with a different inference configuration. The model reference may match, yet the relevant execution context does not. A proposed AIBOM records items such as device, batch size, quantisation, and floating-point precision alongside the model identity. This does not guarantee identical outputs across environments. It makes the conditions of comparison visible, so a difference can be investigated rather than dismissed as an unexplained property of “the model.”
The same logic applies to data. A dataset reference need not expose raw records to every person who reads the AIBOM. It can point to an immutable identifier, a version, a transformation history, and access restrictions. That creates a relationship between model and data without violating data-minimisation requirements. It also preserves an important distinction: knowing which dataset version was used is not the same as knowing that the dataset was representative, legally usable, or free of harmful bias. Provenance improves the question; it does not answer every question.
Operational relationships matter for the same reason. Suppose a model is monitored for drift and later retrained. A package list may remain unchanged while the model state and data lineage change. If the AIBOM records the retraining event and its relevant inputs, a downstream reviewer can ask whether the deployed object is still the one previously evaluated. If that connection is absent, a familiar model name can create false continuity.
This connected view also clarifies the role of model cards. Model cards are primarily human-readable documentation about purpose, evaluation conditions, intended use, limitations, and possible biases. They help a person understand what a model is meant to do and where caution is required. An AIBOM is machine-readable supply-chain evidence: it can organise model identity, dependencies, data references, execution context, and external links so that tools and audits can process them consistently.
Neither format replaces the other. A model card can contain a valuable limitation statement that an automated generator cannot infer from a binary. An AIBOM can bind that documentation to a specific model version and connect it to the data, software, and execution context that give the statement meaning. If the card says a model was evaluated under one condition while the deployed system runs under another, the relationship between documentation and execution becomes a question the AIBOM can help expose.
The HF measurement study makes the practical stakes visible. It treats model-card content and repository metadata as inputs to generated AIBOMs, but preserves missing and inconsistent information rather than filling it by hand. That choice means the resulting artefact reflects what a repository actually makes available. A machine-readable document can therefore be complete in a structural sense while still lacking the human-readable limitations, training information, or safety context needed for a reuse decision.
The six domains should not be read as a demand to publish everything to everyone. Some data must remain protected; some operational information may need access controls; and some organisational records may be available only to authorised reviewers. The point is to identify the evidence relationship and its visibility conditions. A provenance record can say that an input exists, identify its version, and specify who may inspect it without distributing the input itself.
From components to accountability
The central shift is from possession to explanation. An SBOM can establish that software components are present. An AIBOM asks how those components participate in an AI system whose behaviour depends on data, model state, configuration, environment, and operation. The six domains provide the vocabulary; the relationships provide the evidence.
That evidence is useful only when the boundaries are honest. A model hash can support identity. A dataset reference can support lineage. An environment fingerprint can support comparison. A role record can support accountability. None of these, alone or together, automatically proves safety, fairness, or fitness for every use. They make it harder to confuse an unknown with a known and easier to investigate a mismatch.
The next practical problem follows directly. If an AIBOM must describe what actually happened—not merely what a developer intended—then it needs a lifecycle for capturing evidence before, during, and after execution. The question is how to move from declared dependencies to observed execution without making the record too costly, too opaque, or too revealing.