Skip to main content
Category: Validation & Testing

Model Assumptions and Limitations

Also known as: Modelling Assumptions and Limitations, Model Assumptions, Model Limitations
Simply put

Model assumptions are the conditions a model treats as true in order to work, such as expecting data to follow a particular pattern, while limitations are the situations where the model becomes unreliable or should not be trusted. For example, a statistical model may assume that its errors behave in a consistent, predictable way, and its output is only as good as the data used to build it and the questions it is asked. Understanding both matters because a model that is used outside the conditions it assumes can produce misleading results.

Formal definition

In modelling practice, assumptions are the explicit or implicit conditions required for a model's outputs to be valid, and limitations are the boundaries beyond which those outputs may be unreliable or invalid. For linear regression specifically, commonly cited assumptions include a linear true relationship between variables, normally distributed errors, and homoscedasticity (equal error variance across observations); violations such as heteroscedasticity (unequal error variance) can be detected and, in some cases, corrected. Limitations frequently arise from data quality, since a model's reliability is constrained by the data used to construct it and the questions it is asked to answer. Note that the specific assumptions differ by model type and technique, so the linear-regression assumptions described here should not be generalized to all models; the evidence available here addresses statistical regression models rather than the full range of machine learning or AI systems.

Why it matters

Model assumptions and limitations sit at the core of model risk management because a model's outputs are only valid within the conditions it presumes to hold. When a model is applied outside those conditions—used on data that violate its assumptions, or asked questions it was never designed to answer—it can produce results that appear precise but are in fact misleading. Documenting assumptions and limitations is therefore a prerequisite for judging whether a model is fit for a given use, and it is central to model validation, which examines whether a model works as intended rather than simply whether it runs.

The practical stakes are illustrated by common statistical assumptions. For a linear regression model, commonly cited assumptions include a linear true relationship between variables, normally distributed errors, and homoscedasticity—equal error variance across observations. Where an assumption such as homoscedasticity is violated (a condition known as heteroscedasticity, or unequal error variance), the model's reliability can degrade in ways that are not obvious from its headline outputs. Some such violations can be detected and, in certain cases, corrected, but this depends on the model type and technique.

Data quality is a frequently cited limitation: a model is only as good as the data used to construct it and the questions it is asked to answer. This means that unstated or poorly understood limitations can quietly undermine decisions built on model output. Note that the specific assumptions above pertain to statistical regression and should not be generalized to all models; the assumptions and limitations of machine learning or other AI systems differ and are out of scope for the regression-focused evidence here.

Who it's relevant to

Model validators and reviewers
Those responsible for assessing whether a model is fit for use rely on documented assumptions and limitations to judge whether the model is being applied within the conditions it presumes. Checking for violations such as heteroscedasticity, and confirming that data quality supports the intended use, are typical parts of this work. Validators should note that the relevant assumptions vary by model type.
Data scientists and model developers
Developers state and test the assumptions underlying a model—such as linearity, normally distributed errors, and equal error variance for a regression model—and identify limitations arising from data quality. Because a model is only as good as the data used to build it and the questions asked of it, documenting these conditions helps others avoid using the model outside its valid range.
Compliance officers and model risk managers
Those overseeing model risk use assumption and limitation documentation to understand where a model may become unreliable and to set controls around its use. Clear statements of scope help ensure a model is not extended to questions or data it was not built for. The regression-specific assumptions here should not be treated as universal across all models or AI systems.

Inside Model Assumptions and Limitations

Stated Model Assumptions
The explicit conditions, premises, and simplifications a model relies upon to produce valid outputs, such as assumptions about data distributions, relationships between variables, stationarity of underlying patterns, or the representativeness of training data. In many model risk frameworks, documenting these is considered a core component of model development records.
Implicit or Embedded Assumptions
Assumptions not explicitly stated but built into methodology, data selection, or design choices, such as assuming historical patterns persist into the future or that proxy variables adequately capture an intended concept. These are frequently the source of unexpected model behavior and are typically harder to identify than stated assumptions.
Limitations of Scope and Applicability
Boundaries describing where a model can and cannot be reliably used, including intended use cases, population segments, input ranges, and time horizons. As commonly defined, using a model outside these boundaries is a recognized source of model risk rather than a model performance issue per se.
Known Weaknesses and Uncertainty
Identified deficiencies, sources of estimation error, sensitivity to inputs, and areas of elevated uncertainty in outputs. Documenting these typically supports downstream monitoring and the establishment of compensating controls.
Conditions That Invalidate Outputs
Circumstances under which assumptions break down and outputs should be treated with caution or disregarded, such as market conditions unseen in training data or structural changes in the modeled environment. This component links assumptions to ongoing monitoring triggers.
Compensating Controls and Mitigants
Measures put in place to manage risks arising from acknowledged assumptions and limitations, such as conservative overlays, expert review, usage restrictions, or enhanced monitoring. These are typically framed as measures that reduce or manage risk rather than eliminate it.

Common questions

Answers to the questions practitioners most commonly ask about Model Assumptions and Limitations.

Does documenting a model's assumptions and limitations mean the model is compliant and its risks have been resolved?
No. Documenting assumptions and limitations is a transparency and risk-communication measure, not evidence of compliance or risk resolution. As commonly framed in model risk management, identifying a limitation makes it visible so it can be monitored, controlled, or compensated for; it does not eliminate the underlying risk or by itself satisfy any regulatory obligation. Whether documentation supports compliance depends on the applicable framework and on how the identified limitations are actually managed, escalated, and mitigated.
Are a model's assumptions and its limitations the same thing?
They are related but distinct, and professionals typically keep them separate. Assumptions are conditions the model treats as given for it to operate as intended—for example, about data distributions, relationships between variables, or the stability of the environment. Limitations describe the resulting boundaries on where and how the model can be reliably used, including circumstances the model was not designed to handle. An assumption that fails to hold in practice often becomes the source of a limitation, but the two serve different purposes in documentation and review.
How should assumptions and limitations be documented so they are useful during model validation?
In many frameworks, documentation is most useful when each assumption is stated explicitly, linked to the reason it was made, and paired with the consequence if it does not hold. Validators typically look for whether assumptions are testable, whether limitations are tied to specific use conditions, and whether both are traceable to the model's design and data. Vague or boilerplate statements tend to be flagged, because they do not let a reviewer assess materiality or design compensating controls.
Who is responsible for identifying and maintaining a model's assumptions and limitations?
Responsibility is commonly distributed across lines of defense without collapsing their distinct roles. Model developers or owners, often associated with the first line, typically identify and record assumptions and limitations as part of development. An independent validation or review function, often associated with the second line, typically challenges whether those assumptions and limitations are complete, reasonable, and material. Because assumptions can become invalid as conditions change, maintenance is generally treated as an ongoing responsibility rather than a one-time task.
How do documented assumptions connect to ongoing monitoring of a model?
Documented assumptions can serve as a basis for defining what to monitor, since a monitoring plan often tracks the conditions on which a model depends. When observed conditions diverge from stated assumptions—such as shifts in input data or in the operating environment—that divergence can signal that a model may no longer perform as intended. It is worth distinguishing this from model performance degradation itself: an invalidated assumption is a potential cause or leading indicator, while performance degradation is an observed decline in outcomes.
How should the materiality of a model's limitations be assessed?
Materiality is typically assessed by considering how a limitation affects the model's intended use and the decisions that rely on it, rather than by cataloging limitations in isolation. Practitioners commonly weigh factors such as the significance of the affected use case, the potential magnitude of error, and whether compensating controls exist. Because materiality depends on context and use, the same limitation may be minor for one application and significant for another, so assessments are generally revisited when a model is reused or its use expands. The specific criteria and thresholds vary by organization and by applicable framework.

Common misconceptions

Documenting assumptions and limitations makes a model safe to use, because the risks have been disclosed.
Documentation records and communicates known assumptions and limitations; it does not by itself reduce the underlying risk. Managing that risk typically requires compensating controls, monitoring, and usage restrictions, and even these are commonly understood to reduce or manage rather than eliminate model risk.
A model breaching its assumptions is the same as the model performing poorly, so performance monitoring alone is sufficient.
Experts typically distinguish these: an assumption may be violated (for example, an input falls outside the intended range) even while performance metrics appear acceptable, and conversely performance can degrade for reasons unrelated to a specific documented assumption. Both assumption validity and performance are commonly monitored separately.
Assumptions and limitations are a development-phase artifact that can be finalized once and left unchanged.
In many frameworks, assumptions and limitations are treated as living documentation that should be revisited when data, use context, or the modeled environment changes, since conditions that were valid at development can cease to hold over time.

Best practices

Distinguish explicitly between stated and implicit assumptions, and make a deliberate effort to surface embedded assumptions in methodology and data selection that are easy to overlook.
Tie each documented assumption and limitation to a concrete monitoring trigger, compensating control, or usage restriction, rather than leaving them as disclosure-only statements.
Define the intended scope of use precisely, including populations, input ranges, and time horizons, and flag out-of-scope use as a distinct risk category from performance degradation.
Treat assumptions and limitations as living documentation, revisiting them when data, business context, or the modeled environment changes, and record the review outcomes.
Ensure limitations are communicated in language accessible to downstream users and reviewers, so those relying on outputs understand where caution or disregard is warranted.
Where a definition, boundary, or invalidating condition is uncertain or contested, state that uncertainty explicitly rather than presenting a single interpretation as settled.