When the Record Is Incomplete
An AI Bill of Materials (AIBOM) is most valuable when it can say not only what was observed, but also where observation or interpretation stopped. This chapter examines the failure paths that turn an apparently complete AI provenance record into partial evidence: dependencies can drift, runtime components can remain hidden, executions can diverge, and vulnerability identifiers can fail to map cleanly. The goal is a bounded judgment—what can be called verified, partially attested, or unresolved for a particular question—and a clear view of how AIBOMs work with, rather than replace, other supply-chain security artefacts.
The important shift is from failure as an exceptional event to uncertainty as a normal property of a changing AI system. A model may be unchanged while its execution environment changes. A package may be present but not identifiable in the vocabulary used by a vulnerability database. A record may be correctly signed while still omitting a dynamic component. If these conditions are compressed into one “complete” or “incomplete” label, the record becomes easier to consume but less useful for deciding what to do.
How an AIBOM becomes uncertain
Start with the symptom: two executions appear to use the same model and software specification, yet their environments or outputs do not match. There is no single explanation. The first possibility is dependency-resolution drift. A workflow may retrieve a library at runtime or inherit a system component whose version differs from the one present during an earlier execution. The source describes this as a difference between nominally identical specifications and effective execution. A semantic version or package name can look stable while the bytes that ran have changed.
A second possibility is unobserved composition. Static package enumeration sees declared application dependencies, but a model-loading path may import a module only when a particular code path is exercised. A container base layer may bring in system libraries outside the application manifest. A transient component may be present during execution and then disappear from the obvious record. The result is not necessarily a malicious event; it is an evidence gap. The AIBOM may describe what was declared while failing to describe the full state that participated in the computation.
A third possibility is execution-context divergence. Parallel work, accelerator differences, stochastic training, random seeds, quantisation, or precision modes can make bit-identical replay difficult. The same model identity does not imply the same numerical path. This does not mean every difference is caused by hardware or that a model cannot be reproduced across environments. It means a reproducibility claim has to include the conditions under which the run occurred. Without those conditions, a reviewer cannot distinguish a changed model from a changed execution context.
A fourth possibility is identifier ambiguity. Vulnerability records and package managers do not always name the same component in the same way. A vendor-patched build, an operating-system package, and a language-specific package can carry different version conventions. A vulnerability database may therefore fail to match a component that is present, or associate an advisory with a component whose actual build is not affected. The source reports that undocumented transient dependencies and version ambiguity were important causes of residual matching errors in its evaluation.
These symptoms have different consequences. Dependency drift threatens replay. Hidden components threaten composition visibility. Context divergence threatens the meaning of “same execution.” Identifier ambiguity threatens vulnerability attribution.