AIBOM vs model cards and datasheets for datasets

Model cards and datasheets document one model or one dataset for human readers. An AIBOM documents a whole system in machine-readable form. They complement each other, and the formats now let one sit inside the other.

Three documents, three purposes

Model cards were proposed by Mitchell et al. in "Model Cards for Model Reporting", presented at FAT* 2019. They are short documents accompanying a trained model that give benchmarked evaluation across conditions, such as different demographic or phenotypic groups, and disclose the context in which the model is intended to be used ^[1].

Datasheets for datasets were proposed by Gebru et al., published in Communications of the ACM in December 2021. They propose that every dataset be accompanied by a datasheet documenting its motivation, composition, collection process and recommended uses, by analogy with datasheets for electronic components ^[2].

An AIBOM is an inventory of all the components an AI system is built from, including models, datasets, software, infrastructure and external services, in a machine-readable format ^[3].

Comparison

Where they overlap

The formats have absorbed the card and datasheet ideas. CycloneDX's modelCard object has three parts: modelParameters (approach, task, architecture, datasets, inputs, outputs), quantitativeAnalysis (performance metrics) and considerations (users, use cases, technical limitations, ethical and environmental considerations, fairness assessments) ^[4]. These map closely to the sections of a Mitchell-style model card.

SPDX 3.0's DatasetPackage includes properties such as dataCollectionProcess, intendedUse, knownBias, dataPreprocessing and hasSensitivePersonalInformation ^[5], which cover much of what a datasheet asks. Its AIPackage adds limitation, metric and informationAboutApplication ^[6].

In practice, many model cards are published as files in model repositories. Hugging Face model cards combine YAML metadata, such as licence, datasets and base model, with Markdown text ^[7], and AIBOM generators can read that metadata.

What only the AIBOM does

• System scope. It includes the serving framework, libraries, hardware and hosted APIs that neither a card nor a datasheet covers.
• Relationships. It records that model A was fine-tuned from model B on datasets C and D and is called by service E.
• Machine checks. It can be validated, diffed and correlated with vulnerability and licence data.
• Integrity. It carries hashes that tie the description to specific artefacts.

What only the card and datasheet do

Cards and datasheets explain. They give reviewers the reasoning behind design choices, the caveats of an evaluation, and the context of data collection, in language a structured field cannot fully capture. The EU AI Act's Annex IV asks for "datasheets describing the training methodologies and techniques and the training data sets used", including provenance, scope and main characteristics ^[8], which suggests regulators expect this explanatory layer as well.

Using them together

1. Write a model card and a datasheet for each significant model and dataset.
2. Carry their structured content into the AIBOM, using modelCard or SPDX AI and Dataset properties.
3. Link the full documents from the AIBOM by URL or attachment.
4. Update all three when the model is retrained. The AIBOM diff shows reviewers when a card may be out of date.

See What is an AIBOM? for the wider picture.

How IntelliXBOM helps

IntelliXBOM ingests CycloneDX AIBOMs with model-card content and SPDX documents with AI and Dataset profiles, validates the fields your policy requires, and keeps version history so changes to models and datasets are visible. It links models and datasets to the business services that rely on them.