Model Cards › Writing Effective Intended Use Documentation

Intended use documentation is one of the most consequential parts of a model card because it directly determines how users interpret the model's appropriate scope. Writing it well requires resisting two opposing temptations: the urge to claim broad applicability (which overstates what has been validated) and the urge to disclaim everything (which provides no useful guidance).

The most useful intended use sections are specific about tasks, domains, languages, and user populations. Compare these two formulations:

Weak: "This model is intended for natural language processing applications in customer-facing contexts."

Strong: "This model is intended for sentiment classification of English-language product reviews in e-commerce contexts. It was evaluated on reviews from electronics, apparel, and home goods categories. It has not been evaluated for reviews in non-English languages, reviews of services (rather than products), or social media text."

The second formulation tells a deployer exactly what has been validated and immediately raises the question of whether their context matches. The first formulation appears to cover almost any text-based customer application, which will lead deployers to use it in contexts far outside what was tested.

Specificity also helps when a model is intended for broad use. Rather than claiming broad applicability without evidence, a well-written card documents the breadth of evaluation that supports the broad claim. "This model is intended for general-purpose text generation tasks. It was evaluated across 42 task categories spanning question answering, summarization, code generation, translation, and dialogue, with results reported separately for each category" is both broad and specific. The breadth claim is anchored by the evaluation evidence.

The task of specifying what has been validated rather than what might work requires developers to know their evaluation coverage. Teams that build evaluation infrastructure early in the development process are better positioned to write specific intended use documentation because they have the evaluation data to back their claims. Teams that treat evaluation as a final step before release often find that they have benchmarked aggregate performance but have not measured coverage across the specific task and domain dimensions that intended use documentation requires.

The user population the model was designed and validated for is often as important as the use case. A medical information model designed for use by trained physicians behaves under different appropriate-use constraints than one designed for health-literate consumers, even if the task description is superficially similar. The intended user section should specify the professional expertise or knowledge assumed in the user, the institutional context (clinical setting, educational platform, enterprise software), and whether human oversight was assumed in the design.

Models designed with the assumption that a human expert reviews outputs before acting on them are often deployed in contexts where no such review occurs. Documenting the oversight assumption makes this gap visible. It shifts the responsibility for missing oversight to the deployer rather than the developer, and it creates a record that allows post-incident analysis to identify where the assumption broke down.

Documenting intended users also requires clarity about the distinction between the model's immediate users and its downstream subjects. A hiring algorithm's immediate users are HR professionals; its downstream subjects are job applicants. A content moderation model's immediate users are platform operators; its downstream subjects are the users whose content gets moderated. The interests and vulnerabilities of downstream subjects are often more consequential than those of immediate users, and a complete intended use section acknowledges both.

Language models deployed through APIs create another user layering issue: the model developer's intended users may be developers building applications, but those developers' users may be end consumers with very different backgrounds, expectations, and vulnerabilities. Model cards intended for a developer audience need to be complemented by consumer-facing documentation when the end-user population differs substantially from the developer audience.

The out-of-scope section requires careful work to be useful. Simply listing "anything not mentioned above" is circular. A productive approach is to enumerate the highest-risk use cases that a naive user might attempt, particularly those that have been observed empirically in similar contexts or that follow predictably from the model's capabilities.

Commonly important out-of-scope categories include autonomous high-stakes decisions without human review, applications to populations significantly different from the evaluation population, languages or dialects not included in training or evaluation, and real-time safety-critical applications where the model's error rate would cause harm at deployment scale.

The rationale behind each out-of-scope item is as important as the item itself. "Not suitable for clinical diagnosis" is a useful warning, but "not suitable for clinical diagnosis because the model was trained on de-identified records from academic medical centers and was not evaluated on primary care or community health center data" is substantially more useful. It tells the reader both what to avoid and why, which enables them to reason about analogous cases not explicitly listed.

Temporal scope is often omitted from out-of-scope documentation. A model with a training knowledge cutoff should document that the cutoff exists and which domains are most affected by it. A general language model with a cutoff in early 2024 might still perform acceptably for historical analysis or general reasoning, but would be clearly out of scope for questions about current events, recent legislation, or rapidly evolving technical fields.