Most builders read a model card the way you read a cereal box: glance at the big number on the front, ignore the panel on the side. The big number is the benchmark table. The panel on the side — intended use, training data, limitations, and the license buried in the YAML header — is the part that decides whether you can actually ship on the model. This is how to read the panel.
A model card is the spec sheet that ships with a model. The format comes from Mitchell et al.'s 2019 paper, which proposed a standard document describing a model's intended use, performance, and limitations. Hugging Face turned it into the README for every model on the Hub: a Markdown file with a YAML metadata block on top. Read it in five passes, in this order — because the order is the point.
Pass 1 — License (it's in the header, and it's go/no-go)#
Read this before you read anything else, so you don't fall for a model you're not allowed to use. The license lives in the YAML metadata at the very top of the card. "Open weights" is not "open license." A model whose weights you can download may still carry:
- a research-only / non-commercial clause,
- an acceptable-use policy that forbids whole categories of application,
- a scale ceiling (some licenses change terms above a monthly-active-user threshold),
- or no stated license at all, which is its own kind of no.
If the license forbids your deployment — commercial use, your industry, your scale — then the benchmark scores, the context window, and the price per token are all irrelevant. This is a hard gate. Clear it first. (For closed API models there's no weights license, but there is a terms-of-service and usage policy that plays the same role; read it the same way.)
Pass 2 — Intended use, and out-of-scope use#
The card states what the authors built and validated the model for — and, on a good card, what they explicitly did not. This matters more than it looks, because "the model can do X" and "the makers validated it for X" are different claims, and the gap between them is your liability.
- Intended use is the set of applications the authors designed and evaluated for.
- Out-of-scope use is the set they call out as unvalidated or discouraged — high-stakes decisions, unlisted languages, safety-critical settings.
If your use sits outside the intended set — or worse, inside the out-of-scope set — you haven't necessarily hit a wall, but you've taken on risk the model's makers declined to. And under documentation regimes like the EU AI Act's Article 53 obligations, the card's stated scope is exactly the reference an auditor reaches for. Treat this section like the "indications and contraindications" on a drug label. (If your product also needs to disclose that it's AI to end users, that's a separate obligation you should already be planning for.)
Pass 3 — Training data#
What a model was trained on determines what it knows, and four things follow directly from it:
- Recency — the data cutoff sets what it's aware of. No cutoff date on the card is a gap you inherit.
- Language and domain coverage — a model trained mostly on English web text will underperform on the languages and jargon it barely saw. If you're building for non-English users or a specialist domain, this section predicts your quality more than the benchmark does.
- Contamination — if the training data overlaps your evaluation set, its scores are inflated for you specifically. You can't check overlap against data you can't see.
- Licensing and PII exposure — models trained on scraped or undocumented corpora carry copyright and personal-data questions downstream to whoever deploys them.
When this section says "proprietary," "undisclosed," or simply isn't there, that absence is the answer: you can't assess any of the four, so you inherit them as unknowns. Not disqualifying — plenty of strong models disclose little — but it should raise how much of your own evaluation you run before trusting it, not lower it. A card that hides its data is asking you to test more.
Pass 4 — Limitations, bias, and ethical considerations#
This is the section experienced teams read first and beginners skip entirely. It's the known failure modes, documented by the people who trained the model — hallucination patterns, demographic bias, brittle behaviors, misuse potential. Read it as your pre-written incident list: the problems here are the ones you'll meet in production, already named for you.
And here's the reliability tell for the whole card: a trustworthy card documents what the model can't do. A card that's wall-to-wall capabilities with no caveats isn't a spec sheet, it's a brochure — and a brochure is a reason to trust the model less, not more, because someone chose to leave the limitations off.
Pass 5 — Now, the evaluation numbers#
Only now do you read the benchmark table, and you read it against the methodology the card names, not as absolute truth. For every number ask three things:
- On what dataset? A score with no named benchmark is meaningless.
- Measured how? Which metric, which prompt, few-shot or zero-shot, self-reported or third-party?
- When? Benchmarks age; an undated score against a year-old baseline tells you little about today.
A number with a named dataset, a named metric, and a date is a claim you can check. A number floating alone — "outperforms leading models" with no table — is marketing. This is the same discipline as reading a coding-agent benchmark or an LLM pricing page: the headline figure is an invitation to check the footnote, not a substitute for it.
The one-line version#
Read a model card in priority order, not top to bottom: license (can I use it?), intended and out-of-scope use (was it built for this?), training data (what does it know, and what don't I know about it?), limitations (how will it fail?), and only then the evaluation (how well, on what, measured how?). Four of those five are the sections nobody reads — which is exactly why they're where the shipping decision actually lives. And if a card skips the limitations entirely, that's not a smaller card. It's a louder warning.
