What can this system reliably do?
Comes up when a client deploys a model in a context it wasn't designed for: new market, new user group, new data type, and the performance degradation isn't visible until something goes wrong.
AI systems are designed and trained for specific contexts. They perform reliably within those contexts and less reliably, sometimes dangerously, outside them. A credit scoring model validated on employed applicants may perform poorly for self-employed or gig-economy workers. A medical diagnostic tool trained on data from one demographic may be less accurate for another. A language model trained on English-language data may mishandle concepts that don't translate culturally.
These limits are known to the people who built the system. They are almost never visible to the people using it.
Model Scope & Limits is the pattern that surfaces this gap: making the system's intended operating envelope visible to the users and operators who need to judge whether to rely on it in a specific situation.
This is related to, but different from, Confidence & Uncertainty. Uncertainty describes how confident the system is within its scope. Scope & Limits describes where the system applies at all. A system can be highly confident and still be outside its scope: that is one of the most dangerous configurations.
Communicate the intended operating scope of an AI system, and signal clearly when a specific case, query, or context falls outside it: so users can make informed judgments about whether to rely on the output.
A plain-language description of what the system is designed for, shown prominently in the interface: "This system was validated for salaried employees with at least 12 months of employment history."
A visible alert triggered when the current case or query has characteristics outside the validated scope: "This applicant is self-employed. Results may be less accurate: specialist review recommended."
A collapsible section in the interface (also linked to the Model Transparency Card, 12) listing known limitations: - Population coverage - Time range of training data - Geographic or linguistic scope - Known edge cases or failure modes
For systems with geographic, demographic, or domain scope, a visual representation of where the model has been validated. Particularly useful for analysts and operators evaluating whether to deploy in a new context.
A three-tier system: - ✓ Within scope: use normally - ⚠ Edge of scope: use with additional review - ✗ Outside scope: do not rely on this output alone
Scope changes across model versions. Showing the model version and training data cutoff date alongside the scope indicator helps users assess whether the current version is appropriate for their situation.
The concept of "seamful design": deliberately making system seams and limits visible rather than papering over them: is directly applicable here. Research shows that surfacing limitations increases user trust when done well, because it signals that the system knows what it doesn't know. An interface that hides its limits until they cause a problem destroys trust in a single incident; an interface that proactively surfaces them builds the kind of calibrated confidence that survives encountering an edge case.
A model card that describes limitations is useful. A real-time scope indicator that triggers when the current case falls outside validated bounds is essential.
Encountering an out-of-scope case is not a system failure: it is the system functioning as designed. The response should be: route to appropriate review, not: display a generic error message.
"This system has limitations" is not useful. "This system was not validated for self-employed applicants, and the current applicant is self-employed" is actionable.
An out-of-scope warning without a clear next step creates anxiety without resolution. Always pair with: "What should happen instead?": human review, specialist routing, alternative tool.
The scope of a model may expand or contract with each update. Scope indicators must be version-aware.
Transparency vs. over-warning
If every case triggers a scope warning, users become desensitized. Calibrate scope warnings to cases where the limitation genuinely applies, not as a blanket legal disclaimer on every output.
Disclosure vs. system abandonment
Surfacing limitations clearly may cause users to distrust the system entirely: even for the cases it handles well. Present scope as a precise boundary, not as a general indication of untrustworthiness.
Technical accuracy vs. user comprehension
The precise description of a model's training distribution may be technically accurate but incomprehensible to non-technical users. Find plain-language equivalents that are accurate enough to be useful without requiring ML expertise.
Uncertainty is within scope. Scope & Limits defines where scope ends. Both are needed for a complete picture of system reliability.
Model cards are the canonical documentation of scope. This pattern surfaces key scope information at the point of use, with a link to the full card for detail.
Out-of-scope cases are the primary trigger for mandatory human review. The two patterns should be directly linked.
For LLMs, "out of scope" manifests as hallucination risk. Scope warnings and grounding indicators address the same underlying problem in different AI system architectures.
Amershi et al. (2019). Guideline G4: "Show contextually relevant information." G17: "Be transparent about the system's limitations." Both directly support the design approach of this pattern. https://dl.acm.org/doi/10.1145/3290605.3300233 - Seamful Design and Ubicomp Infrastructure, Chalmers & Galani (2004) — Guidelines for Human-AI Interaction
introduces "seamful design": the deliberate surfacing of system limitations and seams as useful information rather than embarrassing failures. Foundational for the design philosophy of this pattern
Mitchell et al. (2019) — Model Cards for Model Reporting
the primary framework for documenting model scope, intended use, and out-of-scope use cases. Model cards are the documentation layer; this pattern is the runtime disclosure layer
documents how AI systems validated on one population can produce discriminatory outcomes when applied to another. The empirical basis for why scope and population coverage limits matter for fairness, and why out-of-distribution use constitutes a genuine harm risk