AI Bill of Materials

An AI Bill of Materials (AIBOM) is a structured inventory of every component that goes into an AI system: model weights, training datasets, fine-tuning data, code, prompts, configurations, and dependencies. AIBOM is the AI-specific evolution of the software SBOM and is now a baseline requirement in regulated industries and federal procurement.

A ModelKit contains every piece of information an AIBOM needs, and Hub stores those ModelKits with the integrity properties an SBOM program depends on. The SBOM document itself is generated by your SBOM tooling against the ModelKit, in whatever format your compliance program requires (typically SPDX 3 or CycloneDX).

A standard SBOM is not enough for AI

Software SBOMs were designed for code dependencies. They enumerate libraries and packages but have no native representation for model weights, training datasets, fine-tuning configurations, prompt templates, or the lineage between them. Two models trained on different data can have identical software SBOMs and produce very different behavior in production.

An AIBOM extends the inventory to cover what actually determines AI behavior:

• Model weights: which weights, which version, which digest.
• Training data lineage: which datasets were used to train, fine-tune, or evaluate the model, and where they came from.
• Configurations and prompts: which settings, skill files, and system prompts shipped with the artifact.
• Code and dependencies: the conventional SBOM content.
• Component provenance: source registry, repository, and tag for every component.

Regulators and procurement teams need this level of detail to answer questions like "did this model train on data it was not supposed to see" and "is the model running in production the one that was approved."

Why ModelKits are ideal for an AIBOM

A ModelKit package bundles every component of an AI project into a single OCI artifact. The format is defined in the ModelPack specification, a CNCF-governed standard authored by Jozu's CTO. The properties that matter for AIBOM are inherent to the format:

• Every component is enumerated. Model weights, datasets, code, configs, prompts, and policies are explicit layers in the ModelKit, not opaque blobs. SBOM tooling can read the ModelKit structure directly and produce an inventory without guesswork about what's inside.
• Every component has a digest. ModelKits use content-addressable storage with SHA-256 digests, so every component reference in an SBOM ties back to bytes that can be verified independently.
• The packaging is open and portable. ModelPack is a CNCF specification and ModelKits are OCI artifacts, so the same SBOM can describe the artifact regardless of which OCI registry it lives in. SBOMs generated against a ModelKit are not locked to Jozu tooling.
• Lineage is preserved by version. ModelKit tags are immutable. An SBOM generated against v1.2 describes exactly that version, and v1.3 is its own SBOM.

For an SBOM program, the practical effect is that the work of "figuring out what's actually in the artifact" is already done by the packaging format.

Why Jozu Hub further increases security for AIBOMs

An AIBOM has value only if the artifact it describes is the same artifact running in production. That requires both tamper-evidence on the artifact and a single source of truth for which version was approved.

• Content-addressable storage. Every ModelKit in Hub is pinned to a SHA-256 digest. An SBOM generated against sha256:abc... describes that exact artifact in any environment, including air-gapped ones.
• Tamper-evident audit trail. Hub's audit repository records every push, scan, attestation, and policy decision in a cryptographically chained log. An auditor can verify that the artifact described by an SBOM has not been modified since it was signed.
• Attestations as machine-verifiable companions. Hub attaches signed attestations for scan results and other events directly to the artifact. The SBOM provides the human-readable inventory; the attestations provide the machine-verifiable proof of what was scanned and approved.
• Air-gapped and disconnected operation. ModelKits stored in a self-hosted Hub remain available for SBOM generation and verification with no external network dependency.

Regulatory context

AIBOM and SBOM obligations are now baseline requirements in several frameworks. Verify against current documentation before making specific compliance claims, since the exact obligations vary and continue to evolve:

• SWFT: SBOM generation requirement for software supplied to DoD environments.
• EO 14028: Federal SBOM requirement for software sold to the US government.
• EU AI Act: Supply chain transparency obligations for AI systems placed on the EU market.
• FedRAMP: SBOM as part of the security documentation package.

ModelKits stored in Jozu Hub give an SBOM program the inventory structure and integrity guarantees it needs to produce evidence that holds up in audit.