AIBOM
AIBOM = AI Bill of Materials, per the arXiv 2603.10057 proposal. It's the inventory of every model, dataset, dependency, and asset a skill references — declared in the manifest, recorded in the transparency log, and exposed on the Skill Report Card.
Coming soon. Today the
capabilities manifest captures a subset (filesystem, network, process). The full AIBOM extension lands with the creator portal.What it covers
- Models — which LLMs the skill calls. Vendor + model ID + endpoint URL.
- Datasets — any data the skill loads at runtime or assumes is available locally.
- Dependencies — bundled scripts and the packages they import.
- Training-data lineage — when a skill ships with a fine-tuned model, the source of that training data.
- Upstream skill dependencies — if skill A imports skill B, AIBOM records the chain. This feeds the upcoming trust-graph analysis.
Why it matters
Three reasons:
- Supply-chain visibility — when a CVE drops against, say, a popular embedding model, the AIBOM tells us every skill that uses it. Continuous re-scan (planned) flips them to quarantine without manual review.
- Compliance evidence — SOC 2 + ISO 42001 require you to document what your software is made of. AIBOM is the AI-shaped equivalent of an SBOM, plug-and-play for audit packages (planned).
- Trust signals — a skill that declares a model from a vendor you don't trust is now visibly suspect, before you install it.
Standards we're tracking
- arXiv 2603.10057 — the AIBOM proposal we're implementing
- arXiv 2602.13682 — VeriSBOM, verification framework for AI BOMs
- SPDX 3.x AI extension (W3C, draft)
See also
- Capability manifest — the v0 subset
- Verified creators — who's allowed to publish AIBOMs and at what verification level