One model card, three readers.
Fill the card once. It is checked against the published schema, read against the documentation duties it can evidence, and exported as a Hugging Face style card, a CycloneDX 1.7 ML-BOM component and the record itself.
Indicative, not legal advice and not a conformity claim. Nothing you enter leaves your browser.
JavaScript is off or has not loaded, so the form, the checklist and the exports are not available. The questions, the criteria and the guide below still work as a worksheet you can read and fill in by hand.
Built from 14. Governing AI development of the Body of Knowledge. Runs entirely in this page: no account and no upload.
One task from the everyday practice of AI governance, defined and compared.
Fix these fields
Your card
| Reference | Requirement | State | Card fields |
|---|
A record exported here, or any record of the model-card schema. Read in this browser; it replaces the form.
How to use it
- Say what the card is read against: part of a high-risk system, a general-purpose AI model, both or neither. That switches the EU AI Act parts of the checklist on or off.
- Fill what you know. Leave the rest empty: the Hugging Face card marks it "[More Information Needed]", as the Hub template does, and the checklist shows the gap.
-
Choose "Check the card" to validate the record against the
model-cardschema, then download the formats you need. Keep the JSON record next to the model: the other two are generated from it.
A model card describes one trained model; most risk sits in the system around it, so for a system with tools or retrieval, fill the oversight and operation fields as a system card [7]. The draft stays in this browser (local storage), not in the link.
By hand, without JavaScript
Use the model card template, which names every field of the record, and read it against the checklist below.
What the checklist reads
Each requirement lists the card fields that evidence it. Covered means every field is filled; partly covered, some. Some requirements live in another artefact the card can only link, such as the risk management system or the declaration of conformity: those read Linked or Not linked. The EU AI Act references are to Art. 11(1) with Annex IV, Art. 13(3) and Art. 53(1) [1]; ISO/IEC 42001 by Annex A control area [5]; the NIST AI RMF by subcategory [6]. A filled field is evidence that the card says something, not that what it says is adequate. Illustrative, not a claim of conformity.
| Reference | Requirement | Card fields |
|---|---|---|
| Annex IV 1(a) | Intended purpose, name of the provider and version of the system | intended_uses , developer , version |
| Annex IV 1(b), (c) | Interaction with hardware or software; versions of relevant software | library , inputs , outputs |
| Annex IV 1(h) | Instructions for use for the deployer (lives in another artefact: Instructions for use (schema)) | links.instructions_for_use |
| Annex IV 2(a) to (c) | Development methods, design specifications and system architecture | training_procedure , architecture_family , architecture |
| Annex IV 2(d) | Data requirements: datasheets, provenance, scope and main characteristics of the data | datasets , training_data |
| Annex IV 2(e) | Assessment of the human oversight measures needed | human_oversight |
| Annex IV 2(f) | Pre-determined changes to the system and its performance | predetermined_changes |
| Annex IV 2(g) | Validation and testing procedures, data and metrics | evaluation_data , metrics |
| Annex IV 2(h) | Cybersecurity measures | cybersecurity |
| Annex IV 3 | Monitoring, functioning and control: capabilities and limitations in performance, including for specific persons or groups | limitations , fairness_assessments |
| Annex IV 4 | Appropriateness of the performance metrics | metrics_rationale |
| Annex IV 5 | The risk management system (Art. 9) (lives in another artefact: Risk register entry (schema)) | links.risk_management |
| Annex IV 6 | Relevant changes made through the lifecycle | change_log |
| Annex IV 7 | Harmonised standards or other specifications applied | standards_applied |
| Annex IV 8 | A copy of the EU declaration of conformity (lives in another artefact: Obligation page, Art. 47) | links.declaration_of_conformity |
| Annex IV 9 | The system to evaluate performance in the post-market phase (lives in another artefact: Post-market monitoring plan (schema)) | links.post_market_monitoring |
| Reference | Requirement | Card fields |
|---|---|---|
| Art. 13(3)(a) | Identity and contact details of the provider | developer , contact |
| Art. 13(3)(b)(i) | Intended purpose | intended_uses |
| Art. 13(3)(b)(ii) | Level of accuracy with its metrics, robustness and cybersecurity | metrics , cybersecurity |
| Art. 13(3)(b)(iii) | Known or foreseeable circumstances, including misuse, that may lead to risks | out_of_scope_uses , limitations |
| Art. 13(3)(b)(iv) | Technical capabilities to provide information that explains the output | explainability |
| Art. 13(3)(b)(v) | Performance for the specific persons or groups it is intended to be used on | metrics[].slice or fairness_assessments |
| Art. 13(3)(b)(vi) | Input data specifications; information on the training, validation and testing data | inputs , datasets |
| Art. 13(3)(b)(vii) | Information to interpret the output and use it appropriately | output_interpretation |
| Art. 13(3)(c) | Changes pre-determined at the initial conformity assessment | predetermined_changes |
| Art. 13(3)(d) | Human oversight measures, including those that help interpret the outputs | human_oversight |
| Art. 13(3)(e) | Compute and hardware needed, expected lifetime, maintenance and care | compute_and_lifetime |
| Art. 13(3)(f) | Mechanisms to collect, store and interpret the logs | logging |
| Reference | Requirement | Card fields |
|---|---|---|
| Art. 53(1)(a) | Technical documentation of the model, including its training and testing process and evaluation results (Annex XI) | training_procedure , metrics , gpai.technical_documentation |
| Art. 53(1)(b) | Information and documentation for providers who integrate the model (Annex XII) | intended_uses , limitations , downstream_use , gpai.downstream_information |
| Art. 53(1)(c) | A policy to comply with Union law on copyright and related rights | gpai.copyright_policy |
| Art. 53(1)(d) | A public, sufficiently detailed summary of the content used for training | gpai.training_content_summary |
| Reference | Requirement | Card fields |
|---|---|---|
| A.4 | Resources for AI systems: data, tooling and compute documented | datasets , library , compute_and_lifetime |
| A.5 | Assessing impacts of AI systems: the impact assessment is linked (lives in another artefact: Impact assessment builder) | links.impact_assessment |
| A.6 | AI system life cycle: design, verification and validation, changes | training_procedure , evaluation_data , metrics , change_log |
| A.7 | Data for AI systems: provenance, quality and preparation | datasets , training_data , preprocessing |
| A.8 | Information for interested parties: uses, limits and a contact | intended_uses , limitations , contact |
| A.9 | Use of AI systems: intended and out-of-scope use | intended_uses , out_of_scope_uses |
| Reference | Requirement | Card fields |
|---|---|---|
| MAP 1.1 | Intended purposes, prospective settings and types of users understood and documented | intended_uses , users |
| MAP 3 | AI capabilities, targeted usage, goals, and expected benefits and costs are understood | description , intended_uses , tradeoffs |
| MEASURE 2.1 | Test sets, metrics, and details about the tools used during TEVV are documented | evaluation_data , metrics |
| MEASURE 2.5 | Validity and reliability shown, with the limits of generalisation documented | metrics , limitations |
| MEASURE 2.9 | The model is explained, validated and documented, and output is interpreted within its context | explainability , output_interpretation |
| MEASURE 2.11 | Fairness and bias are evaluated and the results documented | fairness_assessments |
| MEASURE 2.12 | Environmental impact and sustainability are assessed and documented | environmental |
The Hugging Face style card
A Markdown file with YAML front matter, ready to be a model repository's
README.md. The front matter uses the Hub's metadata keys
(license, language, library_name, tags,
datasets, metrics, base_model)
[3]; the body follows the Hub template's headings, from
Model Details to Model Card Contact, and adds two sections the template lacks: oversight and
operation, and the coverage checklist. The Hub validates a licence against its own list of
identifiers, so use one of those (or other). The model card idea itself comes
from Mitchell et al. [4].
The CycloneDX ML-BOM
A CycloneDX 1.7 document (the current version as of 2026-09-24, released 21 Oct 2025)
holding one component of type machine-learning-model with its
modelCard [2]. It validates against the official
bom-1.7.schema.json, and merges into a larger AIBOM as one component (the
AIBOM pattern) [8]. Every
export gets a fresh random serial number and a timestamp. The fields map as follows:
| Card field | CycloneDX path |
|---|---|
name, version, description | components[0].name, .version, .description |
developer | components[0].supplier.name |
license | components[0].licenses[0].license.name |
tags | components[0].tags |
learning_approach, task | modelCard.modelParameters.approach.type, .task |
architecture_family, architecture | modelCard.modelParameters.architectureFamily, .modelArchitecture |
datasets | modelCard.modelParameters.datasets[] (type "dataset", name, contents.url; role and description as contents.properties) |
inputs, outputs | modelCard.modelParameters.inputs[].format, .outputs[].format |
metrics | modelCard.quantitativeAnalysis.performanceMetrics[] (type, value, slice, confidenceInterval) |
users, intended_uses | modelCard.considerations.users, .useCases |
limitations, out_of_scope_uses | modelCard.considerations.technicalLimitations |
tradeoffs | modelCard.considerations.performanceTradeoffs |
ethical_considerations | modelCard.considerations.ethicalConsiderations[] (name, mitigationStrategy) |
fairness_assessments | modelCard.considerations.fairnessAssessments[] (groupAtRisk, benefits, harms, mitigationStrategy) |
environmental | modelCard.considerations.environmentalConsiderations.properties[] |
repository, links, gpai | components[0].externalReferences[] (vcs, documentation, risk-assessment, attestation, bom) |
What this is not
A card is one part of the technical file, not the file: it does not replace the risk management record, the instructions for use, the declaration of conformity or the monitoring plan, which it links. It does not decide whether the model is high-risk or a GPAI model. The checklist reads the shape of the card, not the quality of its content.
Sources
- [1] Regulation (EU) 2024/1689 (Artificial Intelligence Act), Art. 11(1) and Annex IV points 1 to 9 (technical documentation), Art. 13(3) points (a) to (f) (instructions for use), Art. 53(1) points (a) to (d) and 53(2) (general-purpose AI models); consolidated text of 2026-07-27. EUR-Lex refused automated access on 2026-09-24; the wording was read on the Commission's AI Act Service Desk, which reproduces the Official Journal text. Publications Office of the EU (EUR-Lex). 2026-07-27. https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng#anx_IV (verified: primary)
- [2] CycloneDX specification 1.7 (current version, released 2025-10-21) and its JSON schema bom-1.7.schema.json: component type machine-learning-model; modelCard.modelParameters (approach, task, architectureFamily, modelArchitecture, datasets, inputs, outputs), quantitativeAnalysis.performanceMetrics and considerations (users, useCases, technicalLimitations, performanceTradeoffs, ethicalConsiderations, fairnessAssessments, environmentalConsiderations). OWASP CycloneDX, Ecma TC54. 2025-10-21. https://cyclonedx.org/specification/overview/ (verified: primary)
- [3] Model card metadata specification (license, license_name, license_link, language, library_name, tags, datasets, metrics, base_model) and the model card template. Hugging Face. 2026. https://github.com/huggingface/hub-docs/blob/main/modelcard.md (verified: primary)
- [4] Model Cards for Model Reporting (Mitchell et al.; arXiv 1810.03993). arXiv. 2018-10-05. https://arxiv.org/abs/1810.03993 (verified: primary)
- [5] ISO/IEC 42001:2023, AI management systems (Annex A control areas A.4 to A.9). ISO/IEC. 2023-12. https://www.iso.org/standard/81230.html (verified: primary)
- [6] Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 (MAP 1.1, MAP 3, MEASURE 2.1, 2.5, 2.9, 2.11 and 2.12). NIST. 2023-01-26. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf (verified: primary)
- [7] 14. Governing AI development, "The technical file" and "Model cards, system cards and datasheets". AI Governance Engineering Body of Knowledge. 2026-09-24. https://aigovernanceengineer.com/bok/governing-development#model-cards-system-cards-and-datasheets (verified: primary)
- [8] Model Card as Control Evidence and AIBOM patterns: the card generated from the same records production uses. AI Governance Engineering Body of Knowledge. 2026-09-24. https://aigovernanceengineer.com/patterns/model-card-as-control-evidence (verified: primary)