## Definition A **model card** is a model's published spec sheet: its training-data cutoff, intended use, evaluation results, and known limitations. It is the document you read *before* adopting or upgrading a model — the way you'd read a dependency's changelog before bumping its version. ## What it contains | Field | Why you care | | --- | --- | | **Training-data cutoff** | what the model can and cannot know; recency of facts | | **Intended use** | the tasks the vendor designed and tested it for | | **Evaluations** | benchmark scores — useful but easy to over-trust | | **Known limitations** | documented failure modes, biases, refusals | | **License / usage terms** | what you're allowed to build and ship | ## Read it like a changelog Treat a model upgrade as a dependency bump, not a free win. A new version can regress on a task you depend on, shift its refusal behavior, or change output formatting. The model card is the release note that tells you what moved — read the diff between versions before you upgrade in production. ## Capability is not in the parameter count You cannot read a model's usefulness off its [[Parameter]] count or its [[Scaling Laws]] position. Training data, [[Fine-Tuning]], and [[Alignment]] decisions matter as much as raw size — which is exactly why the card exists. A smaller, well-aligned model can be the better choice, and the card is where you find the evidence. ## Pair it with your own evals A model card is the vendor's claim; your evals are the verification. Vendor benchmarks rarely match your distribution, and they say nothing about your specific failure modes or [[Hallucination]] risk. The discipline: read the card to shortlist, then run your own task-specific evals to decide. Trust, then verify. ## Related - [[Parameter]] - [[Foundation Model]] - [[Scaling Laws]] - [[Alignment]] - [[Hallucination]] - [[Fine-Tuning]] - [[AI Engineering - Chip Huyen]]