Is there one mandatory model-card format?

Formats vary by organization and platform; the core purpose is transparent, relevant reporting.

Can a model card guarantee good outcomes?

No. It describes evidence and limitations that must be assessed in context.

Should it change after retraining?

Yes, when the model version, evaluation results, or relevant usage information changes.

AI Glossary / Statistics and probability / Intermediate

Model card

Definition

A model card is structured documentation that accompanies a machine-learning model and explains its intended uses, evaluation evidence, relevant characteristics, and known limitations. It helps readers judge whether a particular model version is suitable for a particular context. A card communicates evidence and uncertainty; its existence alone does not certify accuracy, fairness, safety, or fitness for every deployment.

What it means

A model name and headline score reveal little about where the model works well or fails. A model card adds context: what was tested, on which data, under what conditions, and for which users or tasks.
The document should be understandable to its intended readers while linking to sufficient technical detail for closer review. It concerns a model and its evidence, so it complements dataset documentation, system documentation, and operational procedures rather than replacing them.

How it works

Identify the exact model version, developer, release information, and relevant technical characteristics. Link evaluation results to that version so readers do not accidentally apply an older score to changed weights, preprocessing, or settings.
Describe intended tasks, users, operating conditions, and uses outside the evaluated scope. Explain output meanings and any decision thresholds. A probability score, ranking, generated answer, and final automated decision should not be described as interchangeable outputs.
Summarize training and evaluation data to the extent supported by available information. Explain data selection, preprocessing, labeling, exclusions, and material gaps. State unknown details explicitly rather than filling them with plausible assumptions.
Present metrics that match the task and consequences of error. Include relevant breakdowns across operating conditions and groups, with sample sizes and uncertainty where appropriate. Aggregate performance can conceal failures affecting less common cases. Group definitions and the basis for using them also need explanation.
Record limitations, foreseeable failure modes, caveats, and recommendations grounded in evidence. Where a proposed safeguard has not been tested, distinguish the proposal from an established mitigation. Links to evaluation reports help readers inspect the basis for claims.
Keep the card current as the model or its evidence changes. A useful maintenance process assigns an owner and preserves earlier versions. Documentation that silently drifts away from the deployed model can mislead even if it was accurate when first written.

Three practical examples

Procurement: compare a supplier's documented evaluation conditions with the languages, document types, and workflows the buyer actually needs.
Internal release: attach a versioned card to a classifier so product teams understand its metrics, thresholds, and unsupported cases.
Model sharing: publish known limitations and evaluation details alongside a model so downstream users can assess whether additional testing is necessary.

Think of it this way

Think of a product's test report and instructions combined. They explain what was evaluated and how the product is meant to be used. A polished cover does not make every claim true; the underlying tests, scope, and honest reporting determine the document's value.

Worked example

A fictional document classifier is evaluated on 1,000 independently labeled examples. Of 900 clear scans, it classifies 882 correctly. Of 100 low-quality scans, it classifies 80 correctly.
Clear-scan accuracy is 882/900 = 98%. Low-quality-scan accuracy is 80/100 = 80%. Overall accuracy is (882 + 80)/1,000 = 96.2%.
A card reporting only 96.2% would conceal a substantial difference between conditions. The corresponding error rates are 2% and 20%, so the observed low-quality error rate is ten times the clear-scan rate.
If a future deployment had equal shares of the two scan conditions and these conditional accuracies remained unchanged, its expected accuracy would be 0.5 times 98% + 0.5 times 80% = 89%.
The last calculation is a scenario, not an observed deployment result. A responsible card would retain sample counts, labeling and selection details, and uncertainty information. It would not assume that the conditional rates remain constant under a new source of documents or a changed preprocessing pipeline.

Illustrative case study

Fictional case: Ridge Archive evaluates an AI document-routing model. Its card initially shows only one aggregate score. A review reveals that poor scans are underrepresented in testing compared with the intended archive.
The team adds condition-specific results and clearly marks untested document types. Before adopting the model, the archive evaluates its own sample and checks the proposed review workflow. The card helps identify the evidence gap, but the document itself does not resolve that gap or establish deployment readiness.

Common misconceptions and mistakes

A model card is not a marketing sheet consisting only of favorable benchmarks. Unavailable information, uncertainty, and unsuccessful evaluations can be important to a reader's decision.
Do not treat reported subgroup scores as a complete fairness assessment. Relevant harms, data quality, context, and the decision process require broader analysis. Small samples may also make apparent differences uncertain.
A model card differs from a dataset card, which primarily describes data. It also differs from a system card or system-level report that may cover components and interactions beyond a single model.
Finally, a model card is not necessarily an independent audit. State who prepared the evidence and what review actually occurred.

Business use

Businesses can use model cards to make evaluation and handover more consistent across development, purchasing, product, and oversight teams. A useful card makes comparison possible without suggesting that incompatible benchmark scores are directly interchangeable. It should help readers locate evidence, identify missing tests, and understand responsibilities for updates. Its practical value depends on accuracy and use in decisions, not on completing a template alone.

Check your understanding

Why did the scenario accuracy fall from 96.2% to 89%?

Answer: The scenario placed more weight on the condition with lower measured accuracy.

What should a card say about an untested language?

Answer: That performance in that language has not been established, rather than extrapolating a general score.

Related terms

Transparency
model documentation
model evaluation
dataset card
system card
intended use
disaggregated evaluation
model versioning

Learn next

review a model card against a concrete deployment scenario, listing which claims are directly supported and which require additional evaluation.

Sources

Sources: Mitchell and colleagues, Model Cards for Model Reporting: https://arxiv.org/pdf/1810.03993 . Hugging Face, Model Cards documentation: https://huggingface.co/docs/hub/model-cards . The primary paper's proposed sections and limitations, and the platform documentation, were checked. Exact NIST AIRC and supplied SLP glossary wording was not independently retrieved. All worked figures and the fictional case are original.

Previous: Model capacity Next: Model cascading