A model card is a short document that accompanies a trained machine learning model and provides benchmarked evaluation in a variety of conditions. It also discloses the context in which the model is intended to be used and details of the performance evaluation procedures.
Machine learning documentation is the subject, not fashion comp cards or model kits. The framework comes from the paper Model Cards for Model Reporting, submitted in October 2018 and published at FAT* ’19, the Conference on Fairness, Accountability, and Transparency. Its authors are Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji, and Timnit Gebru. Popular summaries compress that provenance to one company and one year, dropping the venue and the authorship the arXiv record carries.
Key Takeaways
- A model card is documentation released alongside a trained machine learning model, detailing its performance characteristics and the context in which the model is intended to be used.
- The origin specification proposes 9 sections. The paper itself says the set is not intended to be complete or exhaustive, and that it may be tailored depending on the model, context, and stakeholders.
- According to Hugging Face documentation, a model repo on its Hub renders README.md as the model card, and that Markdown file carries a YAML section at the top holding metadata about the model.
- Google DeepMind publishes a public model card index covering Gemini, generative and robotics models, with a published or updated date against each entry. Gemini 3 Pro carries an update date of 18 November 2025.
- The General-Purpose AI Code of Practice, from the European Commission, was published on July 10, 2025. The Transparency chapter offers a Model Documentation Form that lets providers document the information needed to comply with the AI Act transparency obligation.
How Does a Model Card Work?
A model card passes through three hands: the team that trains the model writes it, the release ships it, and a prospective adopter reads it before committing.
1. The Developer Documents the Model Before Release
The origin paper recommends that released models be accompanied by documentation detailing their performance characteristics. The stated purpose is to clarify the intended use cases of machine learning models and minimize their usage in contexts for which they are not well suited. Authorship sits with the people closest to the training run, because nobody else can describe what was measured and what was skipped.
A nutrition label is the closest everyday analogue. It changes nothing about what is in the packet, and it lets a shopper decide before eating.
2. The Card Travels With the Model File
On the Hugging Face Hub, the model card is the README.md file in a model repo. Metadata a publisher adds to the YAML block at the top of that file supports discovery and easier use of the model, including license display and dataset links. Documentation that lives in the repository cannot drift away from the artifact it describes.
The Transparency chapter of the General-Purpose AI Code of Practice offers all providers of general-purpose AI models a way to demonstrate compliance with their obligations under Article 53 of the AI Act. A convention proposed for researchers now shapes a filing, and the sections below trace how that happened.
3. A Reader Uses It to Judge Fit and Out-of-Scope Use
Model cards report benchmarked evaluation across different cultural, demographic, or phenotypic groups and intersectional groups that are relevant to the intended application domains. A reader compares that reported range against the population their own deployment will touch.
An aircraft type certificate data sheet works the same way. It states the conditions the machine was tested under, and everything beyond them is the operator’s problem to justify.
The origin specification enumerates 9 sections, and the paper states the set is open to tailoring.
| Section | What it records | Why a reader checks it |
|---|---|---|
| Model Details | Developing person or organization, model date, version, type, training algorithms and parameters, citation details, license, contact route | Provenance, license terms, and who to ask |
| Intended Use | Primary intended uses, primary intended users, out-of-scope use cases | Whether the reader’s own case was envisioned |
| Factors | Relevant and evaluation factors: demographic or phenotypic groups, environmental conditions, technical attributes | The conditions performance was broken out by |
| Metrics | Model performance measures, decision thresholds, variation approaches | Which measures were chosen, and where thresholds sit |
| Evaluation Data | Datasets, motivation, preprocessing | What the reported results were measured on |
| Training Data | Mirrors Evaluation Data when possible | What the model learned from, where disclosure allows |
| Quantitative Analyses | Unitary results and intersectional results | The disaggregated performance breakdown |
| Ethical Considerations | Ethical risk the developers identified | Harms the developers already know about |
| Caveats and Recommendations | Remaining concerns and developer recommendations | What the other sections could not settle |
Source: Model Cards for Model Reporting, Section 4
What Problem Do Model Cards Solve?
Trained machine learning models are increasingly used to perform high-impact tasks in areas such as law enforcement, medicine, education, and employment. Those settings raise the cost of a mismatch between what a model was measured on and where it lands.
The documentation exists to clarify the intended use cases of machine learning models and to minimize their usage in contexts for which they are not well suited. The operative phrase there is “not well suited”. A model can perform exactly as measured and still be the wrong instrument for a given job, which is a procurement failure rather than an engineering defect. Readers new to the underlying technology can start with our explainer on how large language models are built and trained.
Hugging Face documentation asks that a model card describe the model, its intended uses and potential limitations, including biases and ethical considerations as detailed in Mitchell, 2018. The largest public model registry points back at the origin paper rather than at a vendor convention of its own.
Who Writes the Model Card?
The origin specification asks the Model Details section to record the person or organization developing the model. The same section records the model date, the model version, the license, and where to send questions or comments about the model. On the Hugging Face Hub, the card sits as the README.md file inside the model repo, a Markdown file carrying additional metadata that drives filtering and license display. Responsibility lands on the releasing team.
Why Does a Model Card Matter?
Google DeepMind describes model cards as simple, structured overviews of how an advanced AI model was designed and evaluated. Its public index carries a published or updated date against each release. Frontier Labs treats the artifact as release infrastructure rather than as an afterthought.
Comparability is the practical payoff. A card discloses the context in which a model is intended to be used and the details of the performance evaluation procedures. Two models documented that way can be read against the same axes.
Our AI benchmark coverage keeps showing capability rankings turning over every few release cycles, which is exactly when a dated document beats a marketing page. Release dates and version histories are tracked separately in our AI model release and version tracker.
Regulatory weight arrived later, with narrower scope than headlines suggest. The General-Purpose AI Code of Practice is a voluntary tool, prepared by independent experts in a multi-stakeholder process. It is designed to help industry comply with the AI Act’s obligations for providers of general-purpose AI models.
A model card earns its value from what it admits. A card with an empty out-of-scope list tells a deploying team nothing, and the sections most likely to run thin are the ones that the team most needs.
Pros, Cons, and Risks
Advantages
- Model cards disclose the context in which models are intended to be used, details of the performance evaluation procedures, and other relevant information.
- Evaluation is reported across cultural, demographic, or phenotypic groups and intersectional groups relevant to the intended application domains.
- Model Details gathers the license, citation details, and the address for questions or comments about the model into a single section.
- Metadata in the YAML block lets users filter models on the Hub, displays the model’s license, and links the datasets used to train the model.
Trade-offs and Risks
- The proposed set of sections is not intended to be complete or exhaustive, and may be tailored depending on the model, context, and stakeholders. Two cards can both be honest and still resist a direct comparison.
- Training Data may not be possible to provide in practice, and the paper asks only that the section mirror Evaluation Data when possible. The weakest section is weak by design.
- Self-reporting carries no external audit step in the origin framework. A card records what the publishing team chose to measure and chose to disclose, which is a limitation of the artifact rather than an accusation against any particular lab.
- Documented limitations and measured failure rates are different things, and the gap between them shows up in measured hallucination rates across leading models.
What a card does not do: A model card documents limitations; it does not remove them, and it certifies nothing. The origin paper states that its proposed section set is not intended to be complete or exhaustive, and that it may be tailored depending on the model, context, and stakeholders. Treat a card as disclosure to be checked, not as assurance to be trusted.
Types of Model Card
Four versions of the artifact circulate, answering to different audiences. The origin specification defines the section set, the platform card makes it machine-readable, the lab card gives a release a dated public record, and the regulatory form turns it into compliance evidence.
| Type | Where it lives | Who publishes it | What it is optimized for |
|---|---|---|---|
| Origin specification | The Model Cards for Model Reporting paper | The paper’s nine authors | A shared section set any developer can adopt |
| Platform card | A README.md file in a model repository | The repository owner on the Hugging Face Hub | Discovery, filtering, and license display |
| Lab card | A standalone published document with an update date | Google DeepMind and comparable labs | Release-level accountability, one card per model |
| Regulatory form | The Model Documentation Form in the Transparency chapter | Providers using the European Commission’s code | Demonstrating compliance with Article 53 obligations |
Sources: Model Cards for Model Reporting, Hugging Face, Google DeepMind, European Commission
Two neighboring terms get mixed in constantly. Data cards and datasheets describe a dataset, while a system card describes a deployed system built around one or more models. Both are terminology distinctions here.
Real-World Applications
Three publishers show the artifact in its working forms:
- A public registry, where the card is a file in the model repository.
- A frontier lab, where each release gets a dated public card.
- A regulator, where the same material becomes a documentation form.
Hugging Face: the Model Card as a README
Model cards on the Hugging Face Hub are simple Markdown files with additional metadata, and a model repo renders its README.md as the card. The metadata block allows users to filter models on the Hub and displays the model’s license. Adding datasets to it links the relevant datasets when they are available on the Hub. Documentation and distribution share one file, which removes the usual excuse for a stale card.
Google DeepMind: a Dated Card per Model Release
Google DeepMind’s index lists a published or updated date against each entry, including Gemini 3 Pro updated 18 November 2025, Gemini 2.5 Pro updated 27 June 2025, and Veo 3 updated 13 January 2026. The index spans Gemini models, generative models for image, music and video, and robotics models such as Gemini Robotics 1.5. Dating each card is what makes the series auditable: a reader can tell which evaluation belongs to which version.
The European Commission: a Model Documentation Form
The Transparency chapter offers a user-friendly Model Documentation Form which allows providers to document the information necessary to comply with the AI Act transparency obligation. The Commission and the AI Board have confirmed that the code is an adequate voluntary tool for providers of general-purpose AI models to demonstrate compliance with the AI Act. Providers who voluntarily sign it can show they comply by adhering to it.
Signatories of the code of practice include Amazon, Anthropic, Google, IBM, Microsoft, Mistral AI and OpenAI, and some signatories may not appear immediately while the list is updated as signatures are confirmed. xAI signed up to the Safety and Security Chapter only, which means it will have to demonstrate compliance with the AI Act’s obligations concerning transparency and copyright via alternative adequate means. Wider regulatory movement across jurisdictions is cataloged in our AI regulation timeline.
Are Model Cards Required by Law?
No blanket legal requirement to publish a model card exists, and the European instrument that comes closest is explicitly optional. The General-Purpose AI Code of Practice is a voluntary tool. It is designed to help industry comply with the AI Act’s obligations on safety, transparency and copyright of general-purpose AI models.
Signing reduces a provider’s administrative burden and gives more legal certainty and trust than proving compliance through other methods. Requirements outside the European Union sit under their own instruments. Cost estimates for the wider regime appear in our EU AI Act compliance cost data.
What Is the Difference Between a Model Card and a System Card?
A model card documents one trained model: what it was built for, how it was evaluated, and where it should not be used. A system card describes a deployed system assembled around one or more models, including the surrounding guardrails, retrieval components, and product surfaces that change behavior at run time.
The distinction is terminology rather than specification, since the origin paper defines only the model-level artifact. In practice, the labels track scope: a model card answers questions about the weights, and a system card answers questions about the product a user actually touches.
Conclusion
The origin specification’s section set runs from Model Details, Intended Use, Factors and Metrics through Evaluation Data, Training Data, Quantitative Analyses, Ethical Considerations and Caveats and Recommendations, and the paper states the set is not intended to be complete or exhaustive. That caveat has held up: the list is a starting point publishers tailor, so comparability across two cards is never automatic.
The audience has changed more than the document has. The Transparency chapter of the General-Purpose AI Code of Practice offers a Model Documentation Form that lets providers document the information needed to comply with their Article 53 obligations. A format written so researchers could read each other’s work is now read by procurement teams, auditors, and a regulator’s form, which is what makes the thin sections worth arguing about.
