What does a model card record about a model's intended use and training population?

## What a model card is A model card is a short, structured document that travels with a trained model, introduced by Mitchell and colleagues in 2019 as a reporting convention. Think of it as the label on a medication: not the chemistry, but what it treats, who it was tested on, what it must not be combined with, and what side effects were observed. Its audience is not the team that built the model — they have the notebooks. Its audience is everyone downstream: the product team wiring it into a workflow, the clinician or underwriter relying on it, the reviewer who has to approve the release, and the engineer who inherits it in two years. ## The sections that carry weight **Model details.** Name, version, date, owning team, contact, model family at a level a non-specialist can parse. Enough to know which artefact this card describes. **Intended use.** The decision the model supports, the users it supports, and the deployment context — stated narrowly and concretely. `Triages incoming dermatology referral photographs so that clinicians review higher-risk cases first` is a usable statement. `Skin lesion classification` is not: it does not say what happens to the output or who acts on it. **Out-of-scope use.** The explicit list of things the model must not be used for. For the same model: not a diagnosis, not a substitute for clinician review, not for body sites absent from the training data, not for patient populations outside the ones evaluated. This section is discussed further below. **Training and evaluation data.** Where the data came from, over what period, how it was collected and labelled, and — critically — who is in it. For an image triage model that means the distribution of skin tones, ages and capture devices, with counts, not adjectives. `Diverse dataset` is a claim nobody can check. A table showing that one tone band holds 3% of images is a fact a downstream reader can reason about. **Performance.** Headline metrics, and then a breakdown across the slices that matter for the use case, each with its sample size so the reader can judge how much to trust the number. An overall figure alone hides exactly the failures the card exists to surface. **Known limitations and ethical considerations.** Where the model is weakest, what happens when it is wrong in each direction, and what mitigations are in place — for a triage model, that a missed high-risk case is far more costly than an over-prioritised benign one, and what the fallback path is. **Maintenance.** Who owns it, when it is reviewed, how to report a problem. ## Why the training population is the load-bearing section Everything a model card says about performance is conditional on the population it was measured on. A downstream team deploying into a clinic whose patient mix differs from the training mix cannot infer the headline number applies to them — but they can only notice that if the card tells them what the training mix was. Recording the skin-tone distribution, with counts, converts an invisible assumption into a stated precondition. When the card also carries the measured drop on under-represented tones, the receiving team can decide whether to deploy, to restrict, or to collect more data first. Without those two facts, that decision is made in the dark and usually made optimistically. Stating the gap does not fix it. It does something more modest and more important: it moves the gap from something discovered in production into something weighed at the decision point. ## Writing the out-of-scope section before launch The hardest section to write honestly is what the model must not be used for, and the temptation is to defer it. Written before launch, it is a design constraint: it forces the team to say out loud that a triage model is not a diagnostic model, and it gives a reviewer something concrete to approve. Written after the first misuse, it is an incident report with a document attached. A workable habit is to write out-of-scope use at the same time as intended use, by asking three questions. What is the nearest neighbouring decision someone might plausibly point this at? Which populations or conditions did we never evaluate? What would a user assume the output means, that it does not mean? A triage score reported as a percentage will be read as a probability of malignancy by somebody unless the card says otherwise. ## Common failure modes - **A card that reads like a training log** — learning rates, architecture trivia, experiment identifiers. Those belong in internal documentation; the card is about use and limits. - **Adjectives where counts belong** — `large and diverse` instead of a distribution table. - **Overall metrics only**, with no slice breakdown and no sample sizes. - **An empty or generic limitations section**, which reads as either dishonesty or inattention. - **A card written once and never versioned**, so it describes a model that has since been retrained on different data. ## What the interviewer is checking That you can name the sections without prompting, that you understand intended use and training population are the two that constrain downstream deployment, and that you treat the card as a release gate written before launch rather than documentation produced afterwards.