An AI Bill of Materials (AIBOM) is an inventory of the AI assets a system depends on: the models it calls, the weights it ships, the datasets it reads, the prompts it sends, and the infrastructure serving them. AIROM produces one by scanning a filesystem, a git repository, a container image, or a set of Kubernetes manifests, and emitting the components it can prove are there — each with the evidence that put it in the list.

​
Why an SBOM is not enough

A traditional SBOM answers “what packages are installed?”. It is built from package manifests: requirements.txt, package-lock.json, go.sum. That model breaks down for AI systems, because the most important assets are not packages. gpt-4.1 has no version in any lockfile. A model file has no package.json. A prompt is just a string. None of these have a purl, a registry, or a manifest entry — so a package scanner walks straight past them.
AIROM is the AI-asset counterpart to software-dependency scanning: a single scanner you point at a target to get a machine-readable inventory. The inputs are entirely different — AI assets are found in code, headers, and configs, not in manifests.

​
The 13 component kinds

Every component AIROM emits has exactly one kind. The kinds are deliberately AI-native: a hosted model reference and a local weights file are different things, with different identity rules and different data attached.
hosted-llm and local-model-file are the two kinds people expect. ai-config is the one worth understanding early — it exists so that a generation parameter AIROM cannot bind to a specific model is still reported rather than dropped. See confidence for why those tend to be low-confidence.

​
What a component carries

Beyond kind and name, a component carries whatever AIROM could substantiate:
Canonical name, optional group (openai, meta-llama), version, provider, and a purl when — and only when — the package URL spec defines a type for it. Hosted API models get no purl: minting pkg:generic/openai/gpt-4.1 would misuse the spec and pollute purl-keyed consumers. Their identity travels as properties instead.
Hashes, download location, release time, and a human-readable source trail. A local model file gets a SHA-256 whenever the whole file was read — AIROM never lets a truncated prefix hash masquerade as a file hash, so weights larger than --max-file-size (default 1m) are identified from their header without one.
Exactly one kind-family facet. Model components carry architecture, parameter count, quantization, context length, format, and base model. Dataset and prompt components carry format, size, and URL. Infra and service components carry endpoint, region, and deployment. Framework and library components carry an ecosystem.
An assembled confidence in [0,1] and every occurrence behind it. This is the part no package scanner has an analogue for. See evidence.

​
Relationships

AIROM emits typed, evidenced edges between components — each backed by the call site that proves it.
In CycloneDX output, the dependencies[] array comes out empty today. The writer maps depends-on edges into it, but no shipped detector or rule pack emits a depends-on edge — AIROM does not fabricate one it cannot substantiate. Other edge types survive as documented airom:rel.* properties, and relationships survive in full in the native json and yaml outputs.

​
Output formats

The same inventory projects into several formats. Select them with -o (repeatable) or --format.
Emit several formats at once

​
Standards status

CycloneDX is the supported SBOM projection today, including its evidence blocks — the part of the spec that most tools leave empty. SPDX 3.0.1’s AI profile and attestation verification are reserved for v2.

Evidence model

How every claim is anchored to a file, a line, and a detector.

Confidence

How the engine assembles a score, and how to filter the noise.