Model Limitations Card¶

Companion artifact — instantiates Uncertainty Explicitness

A short document that travels with a model, dataset, or calculation and states where it is valid, where it is uncertain, and where it is unsafe to use — so an authoritative-looking output cannot be trusted beyond the conditions it was built for.

A Model Limitations Card attaches uncertainty to an automated or authoritative output — a model, dataset, calculator, or algorithm — by stating its validity domain: the conditions under which its results can be trusted, and the ones under which they cannot. Its distinguishing move among its siblings is that it guards against a specific danger — travel. A confident model output detaches from its context effortlessly: a number produced for one population, one time window, one input range gets copied into a decision far outside where it was ever valid, carrying an air of machine authority. The card is the artifact that rides along and says, in plain terms, "valid here, uncertain there, do not use beyond this line" — so the output's limits are inseparable from the output.^[1]

Example¶

A bank deploys a credit-scoring model trained on several years of applicants from a handful of regions. Its scores look objective — a clean number on a screen. The limitations card that ships with it makes the boundaries explicit: it names the sources of uncertainty (the training data underrepresents thin-file and recent-immigrant applicants; economic conditions during training were unusually stable), the assumptions the model requires to stay valid (that application patterns resemble the training window; that a key input field is populated), and — translated for the loan officers who are not statisticians — the unsafe-use cases: "scores for applicants outside the represented groups carry much wider uncertainty; do not treat a borderline score for these cases as decisive — route to manual review." When the bank later expands into a new region, the card is what flags that the model is now operating outside its validity domain, before the mismatch shows up as bad loans.

How it works¶

The card is built around three moves. It inventories where the model's uncertainty comes from — training-data gaps, distributional assumptions, extrapolation beyond the fitted range, drift since training. It logs the assumptions that must hold for outputs to be valid, framed as the boundary of the validity domain (inside: trust; outside: do not). And it translates all of this out of the modellers' language into terms the people consuming the output can act on — an unsafe-use list, not a covariance matrix. What distinguishes it from a technical appendix is exactly that translation-plus-boundary framing: it is written for the downstream user who will be tempted to over-trust the number, not for the model's author.

Tuning parameters¶

Boundary sharpness — crisp go/no-go validity limits versus graded "wider uncertainty here" zones; sharp lines are easy to enforce, graded zones are more honest about a fuzzy edge.
Audience register — technical (distributions, metrics by subgroup) versus operational (a plain unsafe-use list); the card usually needs both layers for its two audiences.
Granularity of failure modes — a few headline limits versus an exhaustive catalogue; too exhaustive and the load-bearing warning is lost in the fine print.
Update coupling — whether the card is refreshed when the model is retrained or the world drifts; a stale card is worse than none because it certifies a validity that has lapsed.
Enforcement — advisory text versus a hard guardrail that blocks out-of-domain use; text is ignorable, a guardrail bites.

When it helps, and when it misleads¶

Its strength is that it keeps a model's authority from outrunning its evidence: the card is what stops an output built for one context from being trusted in another, and it puts the unsafe-use boundary in front of the person who would otherwise never see it. Its failure modes: a card can be written and then ignored, a compliance artifact nobody reads while the model is used freely out of domain; it can understate limits to keep a model deployable; and it goes stale silently as the model drifts or the world changes, certifying a validity that no longer holds. The discipline that guards against this is refreshing the card on every retrain, writing the unsafe-use list for the actual downstream user, and — where stakes justify it — backing the advisory with a hard out-of-domain guardrail rather than trusting the text to be read.

How it implements the components¶

uncertainty_source_inventory — it enumerates where the model's uncertainty originates: training-data gaps, distributional assumptions, extrapolation, and drift.
assumption_log — the validity domain is a log of the assumptions that must hold for outputs to be trustworthy, and the conditions that void them.
stakeholder_uncertainty_translation — it renders modelling uncertainty into an unsafe-use list a non-specialist consumer of the output can actually act on.

It does not represent the numeric uncertainty of any single output (confidence_representation) — that is Confidence Interval and Uncertainty Band — and it does not track the specific unresolved questions the model leaves open (known_unknowns_registry), which is Known Unknowns Log.

Instantiates: Uncertainty Explicitness — it binds a model's validity limits to the model so its authority cannot travel unaccompanied.
Sibling mechanisms: Assumption Register · Uncertainty Band · Evidence Grade Rubric · Known Unknowns Log · Confidence Label · Confidence Interval · Caveated Decision Memo · Forecast Range · Error Bar · Probability Estimate · Risk Register

Notes¶

The card documents the general validity domain of a model; it is not a substitute for per-output uncertainty. A well-carded model can still emit an individual prediction that deserves its own interval or band — the card says "the model is unreliable for this kind of input," while Uncertainty Band or Confidence Interval says "this specific output could vary this much." A mature deployment uses both.

References¶

[1] The practice of shipping a short companion document that states a model's intended use, evaluation conditions, and known limitations — popularized as "model cards," with a parallel practice of "datasheets" for datasets — is a real, widely adopted instance of this mechanism. ↩