Model Card

Model cards address a specific failure: a model built and validated for one narrow purpose gets adopted by another team for a different one, because nothing travelled with it saying what it was for. The second use is outside its validated conditions, nobody notices, and the failure surfaces as poor outcomes for a population the model was never evaluated on.

The content that matters most is the part teams find least comfortable to write: intended use and out-of-scope use, stated explicitly; evaluation results disaggregated by relevant subgroup, because an aggregate accuracy figure conceals systematically worse performance on a minority population, which is exactly the harm the documentation exists to surface; and known limitations, including the conditions under which performance degrades.

For systems built on third-party foundation models, the card should also record the specific model version and provider, since behaviour changes between versions and an undocumented provider-side update is an uncontrolled change to your system.

Under emerging regulation this documentation is moving from good practice to obligation for higher-risk systems, and the practical advice is the same as for architecture decision records: write it while the decisions are being made, when the reasoning is available, rather than reconstructing it a year later for an assessment.