In 2019, Margaret Mitchell, Timnit Gebru, and seven other researchers at Google published “Model Cards for Model Reporting” at the FAT* conference. Their observation was simple but powerful: machine learning models were being shared and deployed with almost no standardized documentation. A model might achieve 95% accuracy on one dataset, but who knew how it performed across different demographics, languages, or edge cases? The paper proposed a simple solution — a short, structured document that accompanies every model, like the nutrition facts on food packaging.

A model card should include: model details (who built it, when, what type), intended use (what it’s for and what it’s not for), evaluation data (how it was tested), performance metrics (broken down by relevant subgroups), ethical considerations, and caveats and recommendations. The key insight was disaggregated evaluation — reporting performance separately across demographic groups rather than just one overall number.

A nutrition label tells you: what’s inside (ingredients/training data), how much of each (macros/parameter count), serving size (context length), allergens (biases and limitations), and recommended use (intended tasks). You don’t need to understand biochemistry to read a nutrition label. You shouldn’t need a PhD in ML to read a model card. Both are designed to help you make an informed choice quickly.

Nutrition labels are legally mandated and standardized. Model cards are voluntary, and every provider structures them differently. There’s no FDA for AI (yet). Some model cards are thorough 20-page documents; others are two sentences and a benchmark table. The quality of the card tells you something about the model maker’s commitment to transparency — and that itself is a useful signal.

On Hugging Face, every model card is a README.md file with a YAML block at the top, enclosed by --- delimiters. This is the part machines read: license type, supported languages, training datasets, pipeline task, base model lineage, and automated benchmark results. This metadata powers search, filtering, and the interactive model widget on the Hub.

Below the YAML is standard Markdown: model description, intended uses, limitations, training procedure, evaluation results, code examples, and citation info. This is where you find the context that numbers alone can’t convey — why certain design choices were made, what failure modes to watch for, and what the model should never be used for.

When you open a model on huggingface.co/models, you see four tabs: Model Card (the README), Files and versions (the actual weights and config), Community (discussions, questions, issues), and any linked Spaces (live demos). At the top: the model name, download count, likes, a “Use this model” button, and the interactive widget that lets you test the model in-browser. On the right sidebar: license badge, pipeline tag, library, base model, and dataset links.

Downloads: High numbers (millions/month) indicate active production use. Likes: Community endorsement — useful but can be inflated. Community tab: Active discussions mean people are actually using it and finding (and fixing) issues. Linked Spaces: If there’s a live demo, you can test the model before downloading anything. These social signals are as important as the technical specs.

The best model cards on Hugging Face follow the annotated template and include: Model Details (developers, model type, language, license), Uses (direct use, downstream use, out-of-scope use), Bias, Risks & Limitations (with specific recommendations), Training Details (data, preprocessing, hyperparameters), Evaluation (testing data, metrics, results), Environmental Impact (carbon emissions, hardware used), and How to Get Started (code snippets). Google’s Gemma model cards are a good example of this thoroughness.

Watch out for cards that: have no “Limitations” section (every model has limitations), show only cherry-picked benchmarks where the model wins, provide no training data information, or are just a copy-paste of the base model’s card with no adaptation for the fine-tuned variant. A model card that says “this model can do anything” is a model card that tells you nothing.

OpenAI — Model Spec: A comprehensive behavioral specification (released under CC0) that defines how models should behave, including chain of command, red-line principles, and default behaviors. Less about architecture, more about alignment.

Anthropic — System Cards: Detailed safety-focused documents covering safeguards, agentic safety, alignment assessment, cyber capabilities, and responsible scaling evaluations. Published for each Claude release.

Google — Model Cards: Follows the original Mitchell et al. framework most closely. Gemma model cards document architecture, training data, hardware, and evaluation with high granularity.

Meta — Llama Model Cards: Published on both Hugging Face and the Meta AI website. Include architecture, training data composition, benchmark tables, and the Llama Community License terms.

Despite the different formats, every provider’s documentation answers the same core questions: What can this model do? (capabilities), What shouldn’t it be used for? (limitations), How was it tested? (evaluation), and What are the risks? (safety). The format varies; the questions don’t.

Model Card (Hugging Face/Google): Focuses on what the model is — architecture, training data, benchmarks, intended use, limitations. Think of it as the model’s birth certificate and report card combined.

Model Spec (OpenAI): Focuses on how the model should behave — behavioral norms, safety boundaries, and default interaction patterns. Think of it as the model’s employee handbook.

System Card (Anthropic): Focuses on whether the model is safe to deploy — comprehensive safety evaluations, red-teaming results, and alignment assessments. Think of it as the model’s safety inspection report.

As someone evaluating models, you’ll encounter all three. For open-weight models on Hugging Face, model cards are your primary source. For API-based models (GPT-4o, Claude, Gemini), you’ll read the model spec or system card on the provider’s website. The skill of reading model documentation transfers across all formats — it’s the same muscle applied to different layouts.

A model card is a contract between the model maker and the model user. It says: “Here’s what I built, here’s what it’s good for, here’s what it’s not good for, and here’s the license under which you may use it.” If you use a model outside its documented intended use and something goes wrong, you can’t blame the model maker — the card told you. Conversely, if the card says “suitable for text classification in English” and you deploy it for medical diagnosis in Japanese, you’ve broken the contract.

Over the next 7 chapters, you’ll learn to read every section of a model card fluently: the YAML metadata (Chapter 2), architecture specs (Chapter 3), benchmark tables (Chapter 4), licensing terms (Chapter 5), file formats (Chapter 6), and how to synthesize it all into a go/no-go decision (Chapter 7). By Chapter 8, you’ll be able to evaluate a new model card in under 5 minutes.