# Model Card Templates Compared: HF, Google, IBM

> Hugging Face, Google Model Cards and IBM AI FactSheets compared section by section, plus the CycloneDX modelCard mapping and a 10-point good-card check.

Source: https://playciso.com/blog/model-card-templates-compared · Published: 2026-10-29 · Publisher: PlayCISO (https://playciso.com)

---

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. What the card saysHugging Face templateGoogle Model Cards (2019)IBM AI FactSheetsCycloneDX 1.7 component Who built it, which version“Model Details”: Developed by, Model type, Language(s), License, Finetuned from“Model Details”: developer, model date, version, type, licenceProvenance facts; in watsonx.governance, lineage events per tracked model`supplier`, `name`, `version`; base model in `pedigree.ancestors` LicenceMetadata `license`; `license_name` + `license_link` when the value is `other`In “Model Details”Not prescribed`licenses` on the component Intended use and users“Uses”: Direct Use, Downstream Use“Intended Use”: primary intended uses, primary intended usersPurpose`considerations.useCases`, `considerations.users` Out-of-scope use“Uses”: Out-of-Scope Use“Intended Use”: out-of-scope use casesNot prescribedNo dedicated field; use `technicalLimitations` Training data“Training Details”: Training Data, Preprocessing; metadata `datasets`“Training Data” (the paper says it “may not be possible to provide in practice”)Provenance`modelParameters.datasets`, pointing to `data` components Evaluation“Evaluation”: Testing Data, Factors & Metrics, Results; metadata `model-index`“Metrics”, “Evaluation Data”, “Quantitative Analyses”Performance`quantitativeAnalysis.performanceMetrics` (`type`, `value`, `slice`, `confidenceInterval`) Results by group“Factors” under Evaluation“Factors” plus unitary and intersectional results: the paper’s core ideaNot prescribed`slice` on each metric; `fairnessAssessments` (`groupAtRisk`, `benefits`, `harms`, `mitigationStrategy`) Limitations and ethics“Bias, Risks, and Limitations”, “Recommendations”“Ethical Considerations”, “Caveats and Recommendations”Safety`technicalLimitations`, `performanceTradeoffs`, `ethicalConsiderations` (`name`, `mitigationStrategy`) Safety and security testingNo dedicated sectionNo dedicated sectionSafety, SecurityNo modelCard field; vulnerabilities go in the BOM’s `vulnerabilities` Architecture, compute, energy“Technical Specifications”; “Environmental Impact” (hardware type, hours used, cloud provider, compute region, carbon emitted)Training algorithms and parameters, in “Model Details”Not prescribed`architectureFamily`, `modelArchitecture`; `environmentalConsiderations` (added in 1.6) Who to contact“Model Card Contact”“Where to send questions or comments about the model”, in “Model Details”Not prescribedContact on `supplier`; `externalReferences` 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 TemplateOwnerFormMachine-readable?Status (Oct 2026)Best for Hugging Face model cardHugging Face`README.md`: YAML metadata plus Markdown sectionsPartly: the YAML blockCurrent. The default for open-weight models on the HubPublishing or ingesting open-weight models Google Model CardsResearch paper: Mitchell et al., FAT* 2019Nine sections with suggested promptsNot in the paper. The Model Card Toolkit stored cards in proto with a JSON schemaFramework current; toolkit archived 27 Sep 2024Deciding what a card must say, especially results by group IBM AI FactSheetsIBM Research (Arnold et al., 2018; methodology by Richards et al., 2020)A methodology, not a fixed template; facts captured in IBM toolingInside IBM watsonx.governance; no open file formatCurrent inside IBM toolingTeams that run model governance in watsonx.governance CycloneDX `modelCard`OWASP / Ecma TC54 (ECMA-424)JSON, XML or Protocol Buffers object on a model componentYes, with a JSON schemaSince 1.5; current 1.7Putting card facts in the AIBOM, where tools can check them For how these sit beside SPDX, Croissant and the EU documents, see [AIBOM standards and templates compared](/blog/aibom-standards-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](/blog/model-cards-reviewed-scored), and the same rubric the [Model Card Scorer](/tools/model-card-scorer) applies. - Identity and version. Developer, model name, version or release date, model type. A SOC analyst needs the exact version when something goes wrong. - Licence. An SPDX id, or a custom licence linked to its text. Legal reads this first. - Intended use. What the model is for, and for whom. - Out-of-scope uses. What it must not do. This is the line your acceptable-use policy and your guardrails enforce. - Training data. Which sources, how much, up to when. Without it you cannot judge licensing, privacy or data-poisoning exposure. - Evaluation results. Named benchmarks with numbers, ideally broken down by group or condition. - Limitations. Specific to this model: languages, domains, measured failure rates. “May be inaccurate” is not a limitation. - Safety testing. What was red-teamed and what mitigations exist, or a plain statement that there are none. - Technical specifications. Architecture, parameters, context length, compute. - 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](/blog/aibom-evaluation-intended-use-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](/tools/aibom-template-library) (Pro). For every field in the BOM version, see [CycloneDX ML-BOM: fields and a worked example](/blog/cyclonedx-ml-bom-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](/aibom). ## 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._