Model Card — AI Glossary

Reference details

Related terms

• AI Alignment
• Evaluation Benchmark

How it works

1. A card is organised by question rather than by result: what the model is for, what it was trained on, how it was evaluated, and where it should not be used.
2. Intended use is stated alongside out-of-scope use, so the document records a boundary rather than a capability claim.
3. Evaluation is reported with the factors it was disaggregated by — language, domain, demographic group — because an aggregate number conceals precisely the failures a deployment decision needs.
4. Training data is described by provenance and collection method, which is what lets a reader judge whether their own population is represented.
5. Limitations and ethical considerations are authored rather than derived, and they are the sections that make a card capable of supporting a decision not to deploy.
6. Because the format is fixed, cards are comparable across models in a way that each provider's own announcement material is not.

Example: What a card is worth is measured in the questions it closes

Consider evaluating 12 candidate models for a deployment. Reading a complete card takes perhaps 25 minutes, so the whole shortlist is 12 x 25 = 300 minutes, exactly 5 hours. Establishing the same facts without cards means testing behaviour, reading papers and writing to vendors — call it 4 hours per model, so 12 x 4 = 48 hours. The ratio is 48 / 5 = 9.6, and that is the conservative version, because several of the facts a card states cannot be recovered by testing at all: no amount of probing establishes what a training corpus contained or which groups an evaluation was disaggregated by. Partial cards are common, and which sections are missing matters more than how many. Against the nine sections of the original schema, a card filling five is at 5 / 9 ≈ 55.6%, and the 9 - 5 = 4 it omits decide what the document can be used for. Four of the nine carry the weight for a deployment decision: limitations, ethical considerations, disaggregated evaluation, and training data provenance. A card covering intended use, metrics and model details documents the case for the model; those four are what would document the case against it. So the useful reading of a card is which sections it answers rather than how long it is — and the sections whose absence is easiest not to notice are the ones that would have told you not to proceed.

Commonly confused with

A model card is not a benchmark report, and reading it as one inverts its purpose. A benchmark report establishes how well a model performs; a card establishes the conditions under which those numbers mean anything — what was measured, on whom, and what was not measured at all. The most valuable content in a good card is therefore negative: the out-of-scope uses and the unevaluated populations. It is also not a system card, though providers increasingly publish both and the names get used interchangeably. A model card documents a model; a system card documents a deployed system including its safety mitigations, filters and operational controls, and the same model can appear in several system cards with different risk profiles.

When to use it

Reach for it when:

• When shortlisting models for a deployment, where the worked comparison recovered roughly 9.6 times the reading time.
• To establish facts testing cannot recover, such as training data provenance and which factors an evaluation was disaggregated by.
• Read for section coverage rather than length, since the four commonly missing sections are the four that support a refusal.
• As the document to publish for a model you release, where a fixed format makes your model comparable with others.

Reach for something else when:

• As evidence of quality, which is what a benchmark report addresses and a card deliberately does not.
• Treated as complete because it exists, when roughly half the schema is routinely unfilled.
• In place of a system card for a deployed product, which documents mitigations a model card has no view of.
• As a substitute for evaluation on your own workload, since no card describes your data.

Primary source

• Mitchell et al., Model Cards for Model Reporting (arXiv)

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Model Card — AI Glossary.

• Browse models
• Review providers
• Inspect benchmarks
• Explore workflows
• Learn AI concepts
• Read decision guides
• Review trust and methodology
• Start a decision path