AIBOM JSON response

This page describes the aibom_info section of the scan result, for integrations that parse it. For what AIBOM detects and how to read it, see AI Bill of Materials (AIBOM) (Beta).

JSON structure

"aibom_info": {
"final_verdict": {
"verdict": "<string>",
//"AI Components Found" | "License Risk Found" | "No AI Components Found"
"verdict_explanation": ["<string>"], //one entry, equal to "verdict"
"blocked": "<boolean>", //true only when licensing_component_counts.blocked > 0
"severity": "INFO", //always "INFO"
"total_component_count": "<int>", //number of entries in "components" (repositories, not files)
"licensing_component_counts": { //absent when there are no components; zeros are always emitted
"allowed": "<int>",
"blocked": "<int>",
"unknown": "<int>" //components with no declared license
}
},
"component_group": { //the scanned file; {} when nothing was found
"group_id": "sha256:<hex>", //SHA-256 of the scanned file

Block states

The shape of aibom_info tells you whether AIBOM ran:

Shape

Meaning

{}

AIBOM did not run: it is disabled in the workflow.

err_code + err_details

AIBOM ran and could not finish. err_details is "AIBOM cache unavailable." when the model database is unavailable, and "The module did not complete this scan." otherwise.

final_verdict, component_group, components

AIBOM ran. When it found nothing, the verdict is No AI Components Found, component_group is {} and components is [].

Field notes

  • Absent keys mean "not known". Values are never null, "" or [] in place of an unknown, so "version" in component is a reliable test. Exceptions: the format entry of metadata is always present, the counts in licensing_component_counts always include zeros, and model_card.metrics is carried exactly as the publisher wrote it, null values included.

  • Finding the scanned file in a repository. In a component's hashes[], the entry whose sha256 equals component_group.group_id (without the sha256: prefix) is the file you scanned, under the name that repository gives it. That name often differs from the one you submitted.

  • Header facts versus registry facts. component_group.metadata comes from the file's bytes; everything on a component comes from the publishing registry. If they disagree, for example architecture in metadata against model_card.architecture, that is worth reviewing, not an error in the report.

  • Metadata names are the scanner's own. Entries in metadata use the scanner's names, not the keys inside the file. A GGUF header's general.license is reported as license. Its value is free text the file declares; license buckets come from the repository's declaration, not from it.

  • Component order. Components are sorted by repository id. When exactly one repository keeps the file at its root under the name you submitted, that repository comes first.

Example

A safetensors file submitted as model.safetensors, matched to one repository that keeps it as 1_Dense/model.safetensors:

{
"final_verdict": {
"verdict": "AI Components Found",
"verdict_explanation": ["AI Components Found"],
"severity": "INFO",
"total_component_count": 1,
"licensing_component_counts": {"allowed": 1, "blocked": 0, "unknown": 0},
"blocked": false
},
"component_group": {
"group_id": "sha256:3b5d855b26767da1c16a086c90aef497114c7c0c4451c6fe9df7a0afc2401c86",
"target": "model.safetensors",
"metadata": [
{"name": "format", "value": "safetensors"},
{"name": "parameters", "value": 16384},
{"name": "tensor_count", "value": 1},
{"name": "size_bytes", "value": 65624}
],
"refs": ["pkg:huggingface/NeuML/pylate-bert-tiny@9cb92954e00ee9b127df35354e4714ed5ff70bee"]
},
"components": [
{
"uid": "pkg:huggingface/NeuML/pylate-bert-tiny@9cb92954e00ee9b127df35354e4714ed5ff70bee",