Model Card Templates Compared: HF, Google, IBM

Use the Hugging Face model card template. It is what open-weight models already ship with, its YAML metadata is machine-readable, and its sections come from Google’s 2019 Model Cards paper. Borrow two things from elsewhere: the paper’s results broken down by group, and a CycloneDX modelCard so the same facts sit in your AIBOM.

Who this is for: AppSec and AI-security engineers who write or review model cards at model intake, and GRC leads deciding which template to require from internal teams and vendors.

What are the main model card templates?

Three, plus one machine-readable home for the same facts.

• Hugging Face model card. The README.md in a model repository. A YAML block at the top holds metadata (license, base_model, datasets, pipeline_tag, model-index); the Hub filters and links models on it. The Markdown below follows a template with sections from “Model Details” to “Model Card Contact”. Unfilled fields default to the text [More Information Needed], which makes empty sections easy to find.
• Google Model Cards. The 2019 paper by Mitchell et al. proposed nine sections: Model Details, Intended Use, Factors, Metrics, Evaluation Data, Training Data, Quantitative Analyses, Ethical Considerations, and Caveats and Recommendations. Its key idea is evaluation “in a variety of conditions”, including demographic and intersectional groups. Google’s Model Card Toolkit generated cards from this framework; its repository was archived on 27 September 2024.
• IBM AI FactSheets. Proposed by IBM Research (Arnold et al., 2018) on the model of a supplier’s declaration of conformity, holding “purpose, performance, safety, security, and provenance information”. A 2020 paper gives a methodology rather than a fixed template. In IBM watsonx.governance, factsheets attach to AI use cases in a model inventory and update as tracked models move from development to production.
• CycloneDX modelCard. An object on machine-learning-model components since CycloneDX 1.5, in three parts: modelParameters, quantitativeAnalysis and considerations. It is how the card’s facts get into an AIBOM.

Section-by-section comparison

Each row is one thing a card should say, with where each template puts it. Hugging Face section names are from the huggingface_hub template; CycloneDX field names are from the bom-1.7 JSON schema. FactSheets is a methodology, so “not prescribed” means the papers do not name a section for it, not that a FactSheet cannot hold it.

Two gaps stand out. Neither the Hugging Face template nor the Model Cards paper has a section for security testing, and FactSheets name safety and security without saying how to report them, so red-teaming results end up wherever the author puts them. And the CycloneDX modelCard holds no licence, supplier or contact: those live on the component itself, so a converter that copies only modelCard drops them.

The templates at a glance

For how these sit beside SPDX, Croissant and the EU documents, see AIBOM standards and templates compared.

What does a good model card have?

Ten things. They are the rubric we used to score real cards in Real model cards, reviewed and scored, and the same rubric the Model Card Scorer applies.

1. Identity and version. Developer, model name, version or release date, model type. A SOC analyst needs the exact version when something goes wrong.
2. Licence. An SPDX id, or a custom licence linked to its text. Legal reads this first.
3. Intended use. What the model is for, and for whom.
4. Out-of-scope uses. What it must not do. This is the line your acceptable-use policy and your guardrails enforce.
5. Training data. Which sources, how much, up to when. Without it you cannot judge licensing, privacy or data-poisoning exposure.
6. Evaluation results. Named benchmarks with numbers, ideally broken down by group or condition.
7. Limitations. Specific to this model: languages, domains, measured failure rates. “May be inaccurate” is not a limitation.
8. Safety testing. What was red-teamed and what mitigations exist, or a plain statement that there are none.
9. Technical specifications. Architecture, parameters, context length, compute.
10. Machine-readable metadata and a feedback channel. So tools can read the facts, and people can report a problem.

Points 3 to 8 are the ones an approver reads. They map to the fields covered in AIBOM evaluation, intended use, limitations and risk.

Worked example: Northwind’s model card in two formats

Northwind Health (fictional) fine-tunes mistralai/Mistral-7B-Instruct-v0.3 with LoRA to build Triage Assistant v2.3. Here is an excerpt of its Hugging Face-style card. The datasets entry assumes the data sits in a private Hub organisation; otherwise list it in the text.

---
license: other
license_name: northwind-internal
license_link: LICENSE
base_model: mistralai/Mistral-7B-Instruct-v0.3
base_model_relation: adapter
datasets:
- northwind/support-tickets-2025
pipeline_tag: text-generation
library_name: peft
---
# Model Card for northwind/triage-assistant (v2.3.0)

## Model Details
- Developed by: Northwind Health, Support Engineering
- Model type: LoRA adapter on Mistral-7B-Instruct-v0.3 (Apache-2.0)
- Weights: safetensors, signed with Sigstore in CI

## Uses
### Direct Use
Drafts replies to customer support tickets. A human agent approves every draft.
### Out-of-Scope Use
Medical advice. Sending replies without human approval.

## Evaluation (fictional values)
- answer-accuracy: 0.87 on northwind/triage-eval-v4 (1,200 labelled tickets)
- toxicity rate: 0.2% on an internal red-team set

## Model Card Contact
ai-security@northwind.example

The same facts as a CycloneDX 1.7 component. The datasets entry points by bom-ref to a data component for the ticket set. We validated the full BOM this excerpt comes from against the official bom-1.7 JSON schema.

{
  "type": "machine-learning-model",
  "bom-ref": "model-triage-assistant",
  "group": "northwind",
  "name": "triage-assistant",
  "version": "2.3.0",
  "supplier": { "name": "Northwind Health" },
  "pedigree": { "ancestors": [ {
    "type": "machine-learning-model", "group": "mistralai",
    "name": "Mistral-7B-Instruct-v0.3",
    "licenses": [ { "license": { "id": "Apache-2.0" } } ] } ] },
  "modelCard": {
    "modelParameters": {
      "approach": { "type": "supervised" },
      "task": "text-generation",
      "architectureFamily": "mistral",
      "modelArchitecture": "Mistral-7B-Instruct-v0.3 with a LoRA adapter",
      "datasets": [ { "ref": "data-support-tickets-2025" } ]
    },
    "quantitativeAnalysis": { "performanceMetrics": [
      { "type": "answer-accuracy", "value": "0.87", "slice": "northwind/triage-eval-v4" },
      { "type": "toxicity-rate", "value": "0.002", "slice": "internal red-team set" } ] },
    "considerations": {
      "users": [ "Northwind support agents" ],
      "useCases": [ "Draft replies to customer support tickets for a human agent to approve" ],
      "technicalLimitations": [ "Not for medical advice", "Must not send replies without human approval" ]
    }
  }
}

Northwind Health and its Triage Assistant are a fictional example used across the PlayCISO AIBOM Library. All names, figures and evaluation results for it are invented for illustration.

The full files, including the data components, are in the AIBOM Template Library (Pro). For every field in the BOM version, see CycloneDX ML-BOM: fields and a worked example.

Three mistakes to avoid

• Copying the base model’s numbers. A fine-tune’s card should report the fine-tune’s evaluation. Northwind’s 0.87 (fictional) is on its own eval set, not Mistral’s benchmarks.
• Leaving template text in. Search your cards for [More Information Needed] before release.
• A card that is not versioned with the model. Keep the card in the same repository and release as the weights, and record the version in both the card and the AIBOM.

All AIBOM guides by role are on the AIBOM Library hub.

Frequently asked questions

What is the best model card template?

For most teams, the Hugging Face template. It is the layout open-weight models already use, it carries YAML metadata that tools can read, and it is built on the 2019 Model Cards paper by Mitchell et al. Add the paper’s idea of results broken down by group, and copy the key facts into your CycloneDX AIBOM so they travel with the system.

Is Google’s Model Card Toolkit still maintained?

No. The tensorflow/model-card-toolkit repository was archived on 27 September 2024 and is read-only. The last release on PyPI is 2.0.0, uploaded in April 2023. The Model Cards framework from the 2019 paper is still the reference most templates follow; only the toolkit is retired.

What metadata should a Hugging Face model card have?

At least license (with license_name and license_link if the licence is custom), base_model for any fine-tune, adapter, merge or quantisation, datasets for the training data, and pipeline_tag for the task. The Hub uses these to filter models, link datasets and show the base model. model-index adds structured evaluation results.

What is an IBM AI FactSheet?

A FactSheet is IBM Research’s proposal, modelled on a supplier’s declaration of conformity, for documenting an AI model or service: its purpose, performance, safety, security and provenance. IBM published a methodology for creating them in 2020. In IBM watsonx.governance, factsheets are attached to AI use cases in a model inventory and update as tracked models move toward production.

How does a model card map to CycloneDX?

CycloneDX (from version 1.5) has a modelCard object on machine-learning-model components with three parts: modelParameters (approach, task, architecture, datasets, inputs, outputs), quantitativeAnalysis (performance metrics with slices and confidence intervals) and considerations (users, use cases, limitations, trade-offs, ethical, environmental and fairness considerations). Licence, supplier, version and base model are ordinary component fields.

Do I need both a model card and an AIBOM?

Yes, if you want both people and tools to use the facts. The model card explains one model to a reader. The AIBOM lists every model, dataset and software component in the system, with versions and hashes, for tools. Generate both from one source so they never disagree.

Sources

• Hugging Face Hub docs: model cards and metadata
• huggingface_hub: model card template
• Mitchell et al., Model Cards for Model Reporting (FAT* 2019)
• tensorflow/model-card-toolkit (archived 27 September 2024)
• Arnold et al., FactSheets: Increasing Trust in AI Services through Supplier’s Declarations of Conformity
• Richards et al., A Methodology for Creating AI FactSheets (2020)
• IBM docs: Using AI Factsheets for AI governance
• CycloneDX JSON schemas (bom-1.5 to bom-1.7)

Checked on 29 October 2026. PlayCISO is not affiliated with any organisation named here.