Model Applicability Card¶

Model documentation artifact — instantiates Domain–Codomain Delimitation

A short published document that states what a model is validated for — its intended use, input populations, excluded uses, and the assumptions that must hold — so it isn't trusted outside the conditions it was built and tested under.

A Model Applicability Card delimits the valid use of a statistical or machine-learning model by publishing, in one human-readable place, what it is for and — just as pointedly — what it is not for. Following the model-card format popularised for ML documentation, it names the model, the input populations and contexts it was validated on, the uses explicitly ruled out, the validity assumptions that must hold for its numbers to mean anything, and the claims its outputs may legitimately support. What distinguishes it from its siblings is that the boundary is about generalization and validity, not syntax: a model can accept an input structurally (right shape, right types) yet be entirely out of domain because that input comes from a population, era, or context the model was never trained or tested on. The card exists to stop a model that "runs" from being believed where it doesn't apply.

Example¶

A credit-default risk model is trained on small-business loan applications from one region during a stable economic period. Its Model Applicability Card states the intended use (ranking default risk for small-business term loans in that region), the input population (businesses of a certain size and sector mix), the excluded uses (consumer lending, a different region, sole-proprietor microloans), the validity assumptions (macroeconomic conditions broadly similar to the training era; input features collected the same way), and the output claim (a relative risk score for triage, not a calibrated probability or an automated decline). A product team later wants to reuse it to auto-decline consumer credit-card applications during a downturn. The card makes the mismatch explicit on every axis — wrong population, excluded use, violated macro assumption, over-strong output claim — so the reuse is caught as an out-of-domain application rather than shipped because the model happened to return a number.

How it works¶

The card is organised as a set of scope declarations rather than performance metrics: it names the unit, draws the input domain as a described population/context (not a type), lists excluded uses as an explicit unsupported region, records the assumptions that must hold as preconditions on trust, and states the output codomain as the claims the outputs can bear (a triage score, not a verdict). Its power is that it travels with the model, so a downstream user meeting the model for the first time inherits the boundary instead of having to reconstruct it — or, worse, assume there isn't one.

Tuning parameters¶

Population specificity — how narrowly the validated input population is described. Narrow is honest and safe but limits reuse; broad invites application to groups the model never saw.
Assumption explicitness — how many validity assumptions are surfaced (distribution stability, feature provenance, label definition). More assumptions make silent out-of-domain use harder but can make the model look fragile.
Output-claim strength — whether outputs are framed as scores, probabilities, or decisions. Overclaiming (calling a raw score a "probability of default") is the fastest route to misuse.
Excluded-use breadth — how explicitly off-label uses are enumerated. Naming them prevents plausible-analogy reuse but can never be exhaustive.

When it helps, and when it misleads¶

Its strength is that it makes a model's domain of validity portable and legible, catching the most dangerous error in applied ML — using a model outside the distribution it was validated on, where its numbers look identical but mean nothing.^[1] It also disciplines overclaiming by forcing the output codomain to be stated as claims, not just values. Its limits are those of any document: a card can be stale (the world drifted from the assumptions since it was written), aspirational (describing intended rather than tested scope), or simply ignored by a downstream team under delivery pressure. The classic misuse is treating the card as a compliance checkbox while quietly using the model wherever it's convenient. The discipline is to tie the card to monitoring that flags distribution shift and to route out-of-scope reuse requests through review rather than leaving the boundary to good intentions.

How it implements the components¶

functional_unit_under_scope — names the specific model the boundary applies to, version and all.
input_domain — describes the populations, contexts, and data conditions the model was validated for.
unsupported_case_boundary — the excluded-use section marking populations and applications the model must not be trusted on.
precondition_statement — the validity assumptions (distribution stability, feature provenance) that must hold for outputs to be meaningful.
output_codomain — states what the outputs may legitimately claim (a triage score, not a calibrated decision), bounding the interpretation as well as the value.

It is documentation, not enforcement: it does not machine-check output structure (Output Schema) or values (Output Validation), verify the boundary in code (Contract Test Suite), or govern its revision (Scope Change Review) — and its output bound is a claim-level statement, while the runtime and structural output checks belong to its siblings.

Instantiates: Domain–Codomain Delimitation — the card is a model's published statement of where it is and isn't valid.
Sibling mechanisms: Service Scope Statement · Clinical Indication Criteria · Output Schema · Output Validation · Contract Test Suite · Eligibility Criteria · Type Signature · Input Validation Gate · Scope Change Review · Unsupported Case Triage Workflow

Notes¶

The Model Applicability Card is close in spirit to a Service Scope Statement, and the two are worth distinguishing: the service statement bounds what an institution will deliver and refuse (an output-and-referral commitment to customers), while the card bounds what a model is valid to conclude (an input-population-and-assumption statement to would-be reusers). A model card that drifts into promising outcomes, or a service statement that reads like a validity disclaimer, is a sign the two boundaries have been conflated.

References¶

[1] Distribution shift (dataset shift) — the training and deployment data are drawn from different distributions, so a model's learned relationships no longer hold. It is a real, central failure mode in applied machine learning and precisely the "used outside its validated domain" risk the card's input-population and assumption sections exist to make visible. ↩