What AIBOMs Can Prove—and What They Still Need

The subject of this series is the AI Bill of Materials (AIBOM) as evidence about a composed AI system, not as a renamed software inventory. The final question is what that evidence can legitimately establish when model identity, data lineage, execution context, documentation quality, vulnerability information, and governance all matter at once. A defensible answer must distinguish what is cryptographically bound, what is operationally observed, what is substantively documented, and what still requires human judgment.

The two supplied studies make that distinction unusually clear. The Frontiers study shows how a CycloneDX-compatible AIBOM can be captured across a controlled Trusted Research Environment workflow, enriched with runtime and vulnerability information, and bound to outputs. The Hugging Face study shows what happens on the other side of the boundary: when a generator receives public repository material, the resulting artifact can be structurally valid while much of the AI-specific documentation remains missing. These are not competing verdicts. They describe two necessary conditions for useful assurance.

Two kinds of completeness must meet

An operationally strong AIBOM cannot recover facts that were never documented. A well-documented model repository cannot, by itself, prove the environment in which a downstream system actually ran. Trustworthy use sits at the intersection of those conditions.

The first condition is capture completeness. The AI system's relevant state has to be observed across its lifecycle: the model and declared dependencies before execution, dynamic loading and inference context during execution, and the output and reconciled state afterward. The record needs relationships among the model artefact, data reference, software and container environment, hardware and configuration, execution event, and output. Hashes and signatures can make those relationships resistant to unnoticed substitution or alteration.

The second condition is documentation completeness. The source repository or responsible organisation has to supply information that an execution pipeline cannot infer reliably: purpose, intended use, limitations, evaluation conditions, safety risks, licensing, training-data references, paper or source-code links, and environmental information. A generator can place that material into a machine-readable structure. It cannot invent a truthful limitation statement from a model file.

The difference is visible in the supplied measurements. In its controlled, simulated TRE evaluation, the Frontiers paper reports 98.7% reproducibility fidelity, 96.2% precision for vulnerability matching, and a 63% reduction in manual validation time. Those results show the feasibility of capturing and using richer provenance under the study's conditions. They do not establish that every AI workflow can be observed with the same coverage or that an attested record proves model quality.

The HF study reports a different kind of limitation. Across 97,940 valid generated artifacts, the mean completeness score was 54.31 out of 100. Required structure was fully represented, while model-card documentation averaged 19.51% and metadata 40.00%. The result is not evidence that AIBOM generation failed. It is evidence that a generator can faithfully expose a thin documentation supply chain. The format may be valid precisely because the missing information was preserved rather than silently fabricated.

These findings fit together as a simple dependency. Capture needs something to capture. Documentation needs an execution context if it is to describe the system that actually ran. An AIBOM is strongest when a model's documented identity and limitations are bound to a specific artefact, dataset reference, environment, execution, and output. When one side is missing, the bill should show which claim remains unsupported rather than compressing the gap into a single score.

Consider two apparently similar situations. In the first, a repository supplies a model hash and a package list but no usable dataset reference or limitation statement.