What is a model card?

How it works

A model card usually starts with basic identity information. What is the model called, which version is being described, who produced it, what inputs does it accept, what outputs does it return, and where is it available. That sounds simple, but it matters. Many organisations end up discussing a model family in general terms when the only thing that really counts is the exact version being used in production.

The next part is purpose. A good card says what the model is intended to do, and just as importantly, what it is not intended to do. This is one of the most valuable sections for a leader because it turns broad possibility into clear scope. A summarisation model may be suitable for drafting notes but not for final legal review. An image classifier may work for routing quality checks but not for clinical diagnosis. If the intended use is vague, the rest of the card becomes less useful because the evaluation has no clear target.

Then comes model data and training information. This does not have to reveal every proprietary detail. It should, however, explain enough for a reader to understand the shape of the training process. What kinds of data informed the model. Whether it was pre trained, fine tuned, or adapted from a base model. Whether there were filters, safety tuning steps, or notable exclusions. For open models, this section may be detailed. For commercial models, it is often more limited. Limited is not the same as useless, but a very thin description should lower your confidence.

Evaluation is usually the heart of the card. This is where the developer reports how the model performed in testing. Strong cards do more than display a single headline score. They explain what was measured, on which benchmarks or test sets, in which languages or domains, under what conditions, and with what caveats. For business use, this is where you should slow down. A model can look excellent on general benchmarks and still be a poor fit for your documents, terminology, customers, or risk profile.

The best cards also include slice based or context based results. In other words, not just average performance, but performance under conditions that matter. For instance, results may differ by language, speech accent, image quality, task type, or safety category. This part matters because serious operational failures often hide inside averages. A high overall score can cover a weak edge case that appears every day in your workflow.

A useful model card also states known limitations and failure modes plainly. This section should describe where the model is brittle, where it tends to hallucinate, where it over refuses, where it performs less well, or where the developer lacks confidence. Leaders sometimes treat limitations as a warning sign. In reality, the absence of a limitations section is often the bigger warning sign. Mature teams know where their model is likely to struggle.

Safety, bias, and ethical considerations often appear near the end of the card. The exact format varies. Some cards discuss content safety and misuse. Some discuss subgroup performance or harmful bias. Some set out acceptable use restrictions. Some also describe energy use, licensing, or downstream requirements. The format differs across providers, and current practice is still evolving, but the practical point is the same. The developer should make material trade offs and constraints visible.

Finally, a card should be maintained, not written once and forgotten. A model card is most useful when it is versioned, dated, and updated as the model changes. If a vendor releases a new major version, adjusts safety tuning, or changes deployment channels, you should expect the card to reflect that. If you are building internally, treat the model card as a living control document rather than a launch day extra.