From Declared Dependencies to Observed Execution
An AI Bill of Materials (AIBOM) becomes operational when it records the difference between what a workload declares and what it actually uses. This chapter follows that difference through three moments—before a model is loaded, while the workload runs, and after it produces an output—so readers can see why each moment matters for verification. The practical judgment is whether a provenance record can support replay and audit without pretending that observation is complete or that a cryptographic binding proves the quality of the AI system.
A conventional manifest is usually strongest before execution. It can list the libraries a job is expected to use and the model a developer intended to load. But AI workloads often resolve dependencies dynamically, load model components at runtime, use hardware-specific paths, or produce a state that is not fully described by source files. An AIBOM therefore has to follow the workload through time. Its record is not a snapshot taken at the easiest moment; it is a set of linked observations whose meaning depends on when and how they were captured.
Three snapshots of one workload
The proposed pipeline begins with pre-execution inspection. Before the job runs, agents enumerate declared dependencies using package managers and system-level sources, inspect the model artefact, and establish the initial environment. This is the point at which the workflow's intended composition is clearest. A package list, container identity, and model reference can be recorded before the workload changes state. The result gives the later observations a baseline: if a library appears during execution but not in the initial declaration, there is a concrete difference to investigate.
Pre-execution evidence is not merely administrative. It establishes the first version of the question “What was supposed to run?” The proposed schema can attach a cryptographic model reference to the model binary or exported representation, a reference to the training data and its access conditions, and an identity for the job container. These anchors connect the model and environment before any output exists. They also expose an important boundary: a declaration describes intent, not yet effective use. The model may not load successfully, a dependency may be retrieved later, or a configuration may select a different execution path.
The second moment is runtime observation. The pipeline is designed to track dynamic imports and model loading through hooks and logging middleware, while capturing model state and inference context. That context can include the device, batch size, quantisation, and floating-point precision. Runtime evidence answers a different question from the pre-execution record: “What did the job actually load and under which conditions did it operate?”
This distinction is particularly important for AI systems because a named model is not a complete execution description. The same artefact may be used with different numerical precision or on different hardware. That does not mean the model becomes a wholly different object each time, nor does it guarantee that any difference in output comes from the device. It means that a reviewer needs the context in which the comparison was made. Recording the context makes it possible to separate a model change from an environment change rather than attributing every discrepancy to an unexplained property of the model.
Runtime capture also addresses dependencies that exist only when the code path is exercised. A static package enumeration can miss a transient library, an inherited container layer, or a module loaded by a model-serving path. Observing imports and loading events provides evidence about the effective execution state. It does not offer perfect visibility into every generated component or hardware-mediated behaviour; the operational design reduces a blind spot rather than abolishing it.
The third moment is post-execution reconciliation. After the job finishes, the pipeline captures the resulting state, hashes output artefacts, and binds those outputs to the AIBOM. This stage asks, “What did this particular execution produce, and can the record still account for the path that led there?” It is where declared and observed dependency sets can be compared, missing metadata can be marked, and output identity can be attached to the model and environment evidence.
The three moments have different failure conditions. A pre-execution record may be complete as a declaration but incomplete as a description of effective use. Runtime observation may reveal a component that cannot be resolved to a known version. Post-execution capture may find that the output is available but the provenance chain is partial. The design is strongest when those conditions remain visible. A record that silently drops an unresolved component is easier to read, but less honest and less useful for an audit.
It is helpful to think of this as a state transition rather than a chronology. The job container's launch triggers the move from an intended environment to an active execution. Loading a model and importing a dependency add observations to the runtime state. Completion of the analytic job triggers output capture and reconciliation. At each transition, some identity should persist: the model reference, the container identity, the execution context, and the link to the output. What cannot be observed should remain an unestablished relationship, not be inferred simply because the preceding state looked complete.
The controlled example in the Frontiers study makes this sequence concrete. The authors tested a federated cancer-outcome workflow using XGBoost with SHAP interpretability in a simulated Trusted Research Environment. Before execution, the pipeline could establish the intended model and software environment. During execution, it could observe the workload's active dependencies and model state. After execution, it could attach the analytic artefacts to a digest and compare the reconstructed environment with the record. The example is not a claim that every clinical workflow behaves this way. It shows why an AIBOM must preserve state across transitions when a result is meant to be reproduced or audited later.
This temporal model also clarifies ownership. The pre-execution record is assembled around what the job is permitted and configured to run. Runtime capture belongs at the boundary where the workload actually executes, because a repository or build log cannot see every event inside a running job. Post-execution binding belongs to the component that can identify the final output and preserve its relationship to the recorded state. Treating these as one undifferentiated documentation step makes it difficult to tell whether a missing fact was never declared, never observed, or lost after execution.
Binding evidence to outputs
The fields in the proposed AIBOM matter because they join observations that would otherwise be stranded in separate logs. A model reference identifies the artefact. A training-data reference connects it to an input lineage without requiring the raw data to be copied into the bill. An inference context records the runtime conditions. A container hash identifies the execution substrate. A disclosure-control field records the kind of output control applied. An output digest identifies the result that the workflow is asking another party to trust or reproduce.
This is a chain of questions rather than a pile of metadata. Which model was loaded? Which data reference and transformation history belong to that model state? Which environment and device executed it? Which disclosure control was applied? Which output was produced? If those answers are stored independently, a reader may have all the nouns but no reliable way to establish that they describe the same event. The AIBOM's value lies in the binding between them.
Cryptographic hashes are the first kind of binding. A hash of a model, container, dependency, or output gives later comparison an artefact identity that is less ambiguous than a name or a tag. If a recorded object changes, the mismatch can be detected. The proposed pipeline also describes digital signatures and Merkle-tree or HMAC-based binding so that the AIBOM and its related artefacts can be checked as a connected record rather than as unauthenticated text.
The security value depends on what is trusted around the hash. A signature can show that a recognised key signed a record; it does not, by itself, establish that the signer had the right model, used a representative dataset, or made a sound safety decision. A hash can show that an output is the one that was recorded; it does not prove that the output is correct. Cryptographic integrity protects the relationship between evidence objects. It does not supply the missing substantive evidence about quality, fairness, legality, or fitness for use.
Schema validation adds a different kind of assurance. A structured AIBOM can be checked for required fields, valid types, timestamps, and conformance to the underlying CycloneDX structure plus the proposed extensions. Validation makes malformed or incomplete records easier to reject at a pipeline boundary. It cannot tell whether a populated limitation field is insightful, whether a dataset reference is accurate, or whether the recorded disclosure control was applied correctly. Structural success is a necessary condition for reliable tooling, not a complete interpretation of the system.
The reason to bind outputs, rather than stop at a model manifest, is replay. A later reviewer may need to reinstantiate the software environment, compare dependency sets, check the model identity, and determine whether the recomputed result corresponds to the recorded artefact. The Frontiers study reports that its AIBOM-tracked workflows reached 98.7% reproducibility fidelity in its controlled evaluation, with minor deviations attributed to version drift in dynamically retrieved operating-system libraries that were not included in the original software trace. That result shows what the proposed approach can achieve under the reported conditions. It also demonstrates why post-execution reconciliation matters: the discrepancy was evidence about the boundary of the original record, not a reason to declare the two executions identical.
What richer capture costs—and what it cannot see
More observation creates more work. A pipeline must inspect dependencies, intercept runtime activity, capture model state, query vulnerability information, calculate digests, validate the schema, and preserve signed records. It also has to run within the security and resource constraints of the environment it is observing. In the controlled evaluation, the authors report that automated format checking, dependency comparison, and vulnerability enrichment reduced average analyst time per validation cycle from 110 minutes to 41 minutes, a 63% reduction. They also report a median schema-check latency of 47 milliseconds and a mean vulnerability-enrichment time of 2.3 seconds per SBOM. Those figures describe the tested pipeline, not a universal cost profile. Automation does not make capture free; it moves effort into instrumentation, integration, key management, storage, and interpretation.
There is also a tension between visibility and exposure. A provenance system that copies every sensitive input into a broadly accessible record may be technically detailed but operationally unacceptable. The proposed approach instead allows the AIBOM to bind to immutable data identifiers, versioned metadata, transformations, and access conditions. A later authorised reviewer can follow the lineage under the applicable access rules without receiving the raw dataset as part of the bill. The relationship is retained while the data boundary remains meaningful.
Runtime observation has limits even when the job is isolated. Dependencies can be retrieved after the initial inspection, package identifiers can map ambiguously across ecosystems, and container base layers can hide components outside an application-level manifest. Hardware acceleration, device selection, quantisation, and precision choices can also make a replay diverge even when the model file is unchanged. Recording the execution context makes such deviations explainable and bounded, but it does not force every execution to become identical.
The appropriate response is not to treat an incomplete record as useless or to smooth its gaps away. The design is stronger when it preserves the observed boundary and makes unresolved items visible. An audit consumer needs to distinguish between “the component was checked and found acceptable,” “the component was observed but could not be mapped,” and “the component was never observed.” Those are different operational facts and should lead to different decisions.
The AIBOM is therefore a control for making execution evidence durable, not a guarantee that execution is fully knowable. Its lifecycle begins with declared intent, gains precision through runtime observation, and becomes more useful when outputs and state are reconciled after the job. Its hashes and signatures can make divergence and tampering visible, while its schema can make records processable. The remaining uncertainty is part of the result.
That is why the trust boundary matters next. When the workload runs inside a sensitive, federated research environment, the system must preserve these evidence relationships while controlling who can see the data and how outputs may be released. The question is no longer only how to observe execution, but how to make provenance verifiable without turning verification into data exposure.