Validation and Model Assessment: How to Know When a Mathematical Model Is Credible

Last Updated June 12, 2026

Validation and model assessment evaluate whether a mathematical model is credible enough for its intended purpose. A calibrated model may fit data, but validation asks a different question: whether the model’s structure, assumptions, parameters, outputs, uncertainty, and decision use are supported by evidence.

Mathematical models can be useful without being perfect. They can clarify relationships, test scenarios, organize evidence, support decisions, and reveal uncertainty. But models can also mislead when they are treated as more reliable than the evidence supports. Validation is the discipline of asking how much trust a model deserves, for what purpose, under what conditions, and with what limits.

Model assessment is broader than a single test. It includes verification, calibration review, residual diagnostics, out-of-sample performance, uncertainty analysis, sensitivity analysis, benchmark comparison, expert review, stress testing, and fitness-for-purpose judgment. A model is not simply “valid” or “invalid.” It is more or less credible for a particular use.

Responsible validation does not ask models to achieve impossible certainty. It asks whether the model’s evidence, assumptions, error behavior, uncertainty, and use conditions are understood well enough to support the claims being made. A model may be adequate for teaching, useful for scenario exploration, acceptable for screening, but insufficient for high-stakes prediction or control.

Why Validation Matters

Validation matters because model outputs often travel farther than their assumptions. A graph, forecast, simulation, coefficient, risk score, or scenario result may be used by people who did not build the model and may not understand its limits. Validation provides evidence about whether the model is credible enough for that use.

Without validation, a model can gain authority simply because it is mathematical, computational, or visually polished. A model may fit calibration data while failing under new conditions, hiding systematic error, ignoring important uncertainty, or producing plausible-looking results for the wrong reasons.

Validation does not make a model perfect. It makes the model’s credibility, limits, and evidence more visible.

Back to top ↑

What Validation Is

Validation is the process of assessing whether a model is sufficiently credible for a specified purpose. It asks whether the model’s structure, assumptions, data, implementation, parameters, outputs, uncertainty, and diagnostics support the intended use.

Validation is not a single number. It is a body of evidence. That evidence may include conceptual review, code verification, calibration diagnostics, comparison with observations, benchmark testing, expert judgment, sensitivity analysis, uncertainty analysis, and decision-specific thresholds.

A model may be valid for one purpose and invalid for another. A classroom model may be valid for explaining feedback loops but invalid for policy forecasting. A screening model may be valid for ranking scenarios but invalid for precise prediction. Validation must always be tied to purpose.

Back to top ↑

Validation, Verification, Calibration, and Assessment

Validation is often confused with verification and calibration. These concepts overlap, but they answer different questions.

Verification can pass while validation fails. A model can be implemented correctly but still represent the wrong system. Calibration can also succeed while validation fails. A model can fit historical data but fail on new data or under stress conditions.

Model assessment is the broader practice of collecting, organizing, and communicating the evidence about model quality. It does not reduce credibility to a single pass/fail label unless a specific decision context requires that threshold.

Back to top ↑

Fitness for Purpose

Fitness for purpose is the central principle of validation. A model should be assessed according to what it is meant to do. Explanation, prediction, control, policy analysis, risk screening, scenario exploration, and education require different standards of evidence.

A model with modest predictive accuracy may still be useful for conceptual explanation. A model with good historical prediction may still be inadequate for high-stakes control. Validation should not ask whether a model is universally good, but whether it is good enough for a stated purpose.

Back to top ↑

Conceptual Validity and Model Assumptions

Conceptual validity concerns whether the model’s structure is appropriate. It asks whether the model includes the right entities, relationships, mechanisms, boundaries, scales, assumptions, and simplifications for the question being asked.

A model may produce accurate-looking outputs while being conceptually weak. It may fit data through compensating errors, flexible parameters, or hidden correlations. Conceptual review helps assess whether the model’s internal logic is credible, not just whether its outputs are close to observations.

Conceptual validation is especially important when models are used for explanation, policy, sustainability, public health, infrastructure, or complex systems. In those contexts, a superficially accurate model may still mislead if its causal structure or system boundary is wrong.

Back to top ↑

Implementation Correctness and Verification

Implementation correctness concerns whether the computational model does what the formal model says it should do. Verification checks the translation from equations, assumptions, and algorithms into code.

Verification is not optional. A model can be mathematically sound but incorrectly implemented. Errors may arise from indexing, units, sign conventions, time-step logic, random seeds, solver settings, boundary conditions, data parsing, or output calculations.

Verification asks whether the model was built correctly. Validation asks whether the correct model was built for the purpose. Both are needed.

Back to top ↑

Data Validation and Evidence Quality

Validation depends on evidence quality. Data used to assess a model must be relevant, reliable, aligned with model outputs, and appropriate for the purpose of the validation.

Data validation includes checking missing values, units, measurement error, time alignment, spatial alignment, sampling bias, outliers, transformations, and provenance. If the evidence is weak, validation claims should be modest.

Data validation protects model validation from false confidence. A model cannot be credibly assessed against evidence whose meaning, quality, or provenance is unclear.

Back to top ↑

Residual Diagnostics, Error, and Model Behavior

Residuals are differences between observed values and model predictions. Error diagnostics help reveal whether mismatch is random, systematic, context-specific, or decision-relevant.

A model may have acceptable average error but still fail in important regions, such as extreme values, threshold zones, vulnerable populations, rare events, high-stress conditions, or policy-relevant scenarios.

Model assessment should look beyond a single error score. Diagnostics should ask where the model fails, why it fails, and whether those failures matter for the intended use.

Back to top ↑

Out-of-Sample Testing and Generalization

Out-of-sample testing evaluates model performance on evidence not used to fit the model. This helps distinguish models that merely fit known data from models that generalize to relevant new cases.

Common strategies include holdout datasets, cross-validation, time-split validation, spatial validation, external datasets, and scenario-based stress tests. The right approach depends on the modeling context.

Out-of-sample performance should be interpreted carefully. If future conditions differ from past conditions, even a good validation score may not guarantee future credibility. Generalization is evidence, not certainty.

Back to top ↑

Benchmarks, Comparisons, and External Evidence

Model assessment often becomes clearer when a model is compared with alternatives. A complex model should not be accepted merely because it performs reasonably. It should be compared with simpler baselines, existing methods, external benchmarks, and domain expectations.

Benchmarking helps prevent unnecessary complexity. If a complex model does not outperform a simple baseline for the intended use, its extra structure may not be justified. If it does outperform, validation still needs to explain where, why, and under what conditions.

Back to top ↑

Uncertainty, Sensitivity, and Robustness Review

Validation is incomplete without uncertainty review. A model’s credibility depends not only on its central output, but also on how results change when assumptions, parameters, inputs, model structures, or conditions vary.

Sensitivity analysis examines which inputs or parameters influence outputs. Uncertainty analysis examines the range of plausible outputs. Robustness analysis asks whether conclusions hold under reasonable changes in assumptions.

A model may be accurate on average but fragile under plausible changes. Robust assessment asks not only whether the model fits, but whether its conclusions are dependable enough for the decision being considered.

Back to top ↑

Mathematical Lens: Validation as Evidence for Use

Validation can be represented as an evidence function that assesses model outputs against purpose, observations, uncertainty, and decision conditions.

Prediction error can be summarized through residuals:

Root mean squared error summarizes one form of predictive mismatch:

Fitness for purpose can be framed as a threshold judgment:

This mathematical lens emphasizes that validation is conditional. The same model may meet one threshold and fail another.

Back to top ↑

Example: Assessing a Calibrated Resource Model

Consider a calibrated resource model that estimates future stock under extraction policies. Calibration estimated growth and carrying-capacity parameters from historical stock observations. Validation now asks whether the model is credible enough for scenario analysis or decision support.

The model might be adequate for broad scenario comparison but not for precise annual forecasting. It might support discussion of extraction tradeoffs but not direct regulatory thresholds without more evidence. Validation should state that distinction clearly.

Back to top ↑

Validation for Decision Support

When models inform decisions, validation must be tied to decision consequences. A model used for low-stakes exploration may require less evidence than a model used for public safety, clinical decisions, infrastructure investment, environmental regulation, or crisis response.

Decision support requires more than predictive accuracy. It requires appropriate scope, uncertainty communication, threshold behavior, stakeholder relevance, and transparency about what the model can and cannot support.

A validation report should help decision-makers understand not only what the model says, but how strongly it should influence action.

Back to top ↑

Ethical Stakes of Model Assessment

Model assessment carries ethical stakes because validation language can authorize action. A model described as “validated” may be trusted by users who do not understand its scope, assumptions, limitations, or uncertainty.

Responsible validation avoids false authority. It does not use validation as a stamp of certainty. It presents evidence, limits, error behavior, uncertainty, and decision conditions clearly.

Ethical validation is honest about model limits. It supports trust by making uncertainty and conditional credibility visible, not by pretending uncertainty has disappeared.

Back to top ↑

Python Workflow: Validation Register and Assessment Diagnostics

The Python workflow below creates a dependency-light validation register, compares predictions with validation observations, calculates error metrics, assigns fitness-for-purpose classifications, and writes a model assessment card.

# validation_and_model_assessment_workflow.py
# Dependency-light validation workflow for model assessment and diagnostics.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json
import math
import statistics


ARTICLE_ROOT = Path(__file__).resolve().parents[1]
OUTPUTS = ARTICLE_ROOT / "outputs"
TABLES = OUTPUTS / "tables"
JSON_DIR = OUTPUTS / "json"


@dataclass(frozen=True)
class ValidationRecord:
    key: str
    validation_layer: str
    modeling_role: str
    assessment_question: str
    status: str


@dataclass(frozen=True)
class ValidationObservation:
    time: int
    observed_value: float
    predicted_value: float
    scenario: str


def validation_register() -> list[ValidationRecord]:
    return [
        ValidationRecord(
            key="conceptual_validity",
            validation_layer="conceptual",
            modeling_role="Reviews model structure, assumptions, boundaries, and purpose.",
            assessment_question="Does the model represent the intended system well enough?",
            status="review",
        ),
        ValidationRecord(
            key="implementation_verification",
            validation_layer="verification",
            modeling_role="Checks that code implements the specified model logic.",
            assessment_question="Does the implementation match the model specification?",
            status="active",
        ),
        ValidationRecord(
            key="data_validation",
            validation_layer="evidence",
            modeling_role="Reviews observations, units, provenance, and alignment.",
            assessment_question="Are validation data relevant and reliable?",
            status="review",
        ),
        ValidationRecord(
            key="residual_diagnostics",
            validation_layer="diagnostics",
            modeling_role="Examines residuals, bias, and error patterns.",
            assessment_question="Do residuals show systematic model failure?",
            status="active",
        ),
        ValidationRecord(
            key="uncertainty_review",
            validation_layer="uncertainty",
            modeling_role="Reviews sensitivity, robustness, and uncertainty ranges.",
            assessment_question="Could uncertainty change the model-supported decision?",
            status="review",
        ),
        ValidationRecord(
            key="fitness_for_purpose",
            validation_layer="decision_support",
            modeling_role="Assesses adequacy for the intended use.",
            assessment_question="Is the model credible enough for the stated purpose?",
            status="review",
        ),
    ]


def validation_observations() -> list[ValidationObservation]:
    return [
        ValidationObservation(10, 70.1, 70.8, "holdout"),
        ValidationObservation(11, 68.9, 69.7, "holdout"),
        ValidationObservation(12, 67.4, 68.3, "holdout"),
        ValidationObservation(13, 65.8, 66.9, "holdout"),
        ValidationObservation(14, 64.2, 65.1, "holdout"),
        ValidationObservation(15, 62.1, 63.8, "stress"),
        ValidationObservation(16, 60.4, 61.3, "stress"),
        ValidationObservation(17, 58.8, 59.9, "stress"),
    ]


def error_rows(data: list[ValidationObservation]) -> list[dict[str, object]]:
    rows = []
    for obs in data:
        residual = obs.observed_value - obs.predicted_value
        rows.append({
            "time": obs.time,
            "scenario": obs.scenario,
            "observed_value": obs.observed_value,
            "predicted_value": obs.predicted_value,
            "residual": round(residual, 8),
            "absolute_error": round(abs(residual), 8),
            "squared_error": round(residual * residual, 8),
        })
    return rows


def metric_summary(rows: list[dict[str, object]]) -> dict[str, object]:
    residuals = [float(row["residual"]) for row in rows]
    abs_errors = [float(row["absolute_error"]) for row in rows]
    squared_errors = [float(row["squared_error"]) for row in rows]

    rmse = math.sqrt(sum(squared_errors) / len(squared_errors))
    mae = sum(abs_errors) / len(abs_errors)
    bias = statistics.mean(residuals)
    max_abs_error = max(abs_errors)

    return {
        "rmse": round(rmse, 8),
        "mae": round(mae, 8),
        "bias": round(bias, 8),
        "max_abs_error": round(max_abs_error, 8),
        "n": len(rows),
    }


def scenario_summary(rows: list[dict[str, object]]) -> list[dict[str, object]]:
    grouped: dict[str, list[dict[str, object]]] = {}
    for row in rows:
        grouped.setdefault(str(row["scenario"]), []).append(row)

    output = []
    for scenario, values in sorted(grouped.items()):
        summary = metric_summary(values)
        output.append({"scenario": scenario, **summary})
    return output


def classify_fitness(summary: dict[str, object]) -> str:
    rmse = float(summary["rmse"])
    max_abs_error = float(summary["max_abs_error"])

    if rmse <= 1.25 and max_abs_error <= 2.0:
        return "adequate_for_scenario_screening"
    if rmse <= 2.5:
        return "limited_use_requires_review"
    return "not_adequate_without_revision"


def validation_risk_score(record: ValidationRecord) -> float:
    score = {"active": 1.0, "review": 5.0, "revise": 8.0, "archive": 2.0}.get(
        record.status.lower(),
        4.0,
    )
    text = f"{record.validation_layer} {record.modeling_role} {record.assessment_question}".lower()
    for term in ["conceptual", "data", "residual", "uncertainty", "decision", "verification", "purpose"]:
        if term in text:
            score += 1.0
    return round(score, 3)


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    if not rows:
        raise ValueError(f"No rows supplied for {path}")
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    with path.open("w", encoding="utf-8") as handle:
        json.dump(payload, handle, indent=2, sort_keys=True)


def main() -> None:
    records = validation_register()
    observations = validation_observations()
    errors = error_rows(observations)
    overall = metric_summary(errors)
    by_scenario = scenario_summary(errors)

    register_rows = [
        {**asdict(record), "validation_risk_score": validation_risk_score(record)}
        for record in records
    ]

    write_csv(TABLES / "validation_observations.csv", [asdict(obs) for obs in observations])
    write_csv(TABLES / "validation_error_diagnostics.csv", errors)
    write_csv(TABLES / "validation_scenario_summary.csv", by_scenario)
    write_csv(TABLES / "validation_register.csv", register_rows)

    write_json(JSON_DIR / "model_assessment_card.json", {
        "article": "Validation and Model Assessment",
        "overall_metrics": overall,
        "fitness_for_purpose": classify_fitness(overall),
        "scenario_summary": by_scenario,
        "validation_register": register_rows,
        "use_limit": "Assessment is educational and does not authorize operational decision use without domain-specific review.",
        "diagnostic_checks": [
            "validation observations are separated from calibration logic",
            "residual and error metrics are exported",
            "scenario-level diagnostics are preserved",
            "fitness-for-purpose judgment is conditional",
            "uncertainty and decision-use review remain required",
        ],
    })

    print("Validation and model assessment workflow complete.")
    print(f"Overall metrics: {overall}")
    print(f"Fitness for purpose: {classify_fitness(overall)}")
    print(f"Wrote outputs to {OUTPUTS}")


if __name__ == "__main__":
    main()

This workflow treats validation as evidence organization. It separates validation observations, residual diagnostics, scenario summaries, assessment records, and a model assessment card.

Back to top ↑

R Workflow: Validation Review and Error Diagnostics

The R workflow below reviews generated validation outputs, classifies validation records by priority, and creates a base R residual diagnostic plot.

# validation_and_model_assessment_review.R
# Base R workflow for validation and model assessment diagnostics.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")
dir.create(tables_dir, recursive = TRUE, showWarnings = FALSE)
dir.create(figures_dir, recursive = TRUE, showWarnings = FALSE)

error_path <- file.path(tables_dir, "validation_error_diagnostics.csv")
summary_path <- file.path(tables_dir, "validation_scenario_summary.csv")
register_path <- file.path(tables_dir, "validation_register.csv")

if (!file.exists(error_path) || !file.exists(summary_path) || !file.exists(register_path)) {
  stop("Missing validation outputs. Run the Python workflow first.")
}

errors <- read.csv(error_path, stringsAsFactors = FALSE)
scenario_summary <- read.csv(summary_path, stringsAsFactors = FALSE)
register <- read.csv(register_path, stringsAsFactors = FALSE)

errors$residual <- as.numeric(errors$residual)
errors$absolute_error <- as.numeric(errors$absolute_error)
scenario_summary$rmse <- as.numeric(scenario_summary$rmse)

register$priority <- ifelse(
  register$validation_risk_score >= 8,
  "high",
  ifelse(register$validation_risk_score >= 6, "medium", "low")
)

overall_review <- data.frame(
  rmse = sqrt(mean(errors$residual ^ 2)),
  mae = mean(errors$absolute_error),
  bias = mean(errors$residual),
  max_abs_error = max(errors$absolute_error),
  n = nrow(errors)
)

overall_review$fitness_for_purpose <- ifelse(
  overall_review$rmse <= 1.25 & overall_review$max_abs_error <= 2.0,
  "adequate for scenario screening",
  ifelse(overall_review$rmse <= 2.5, "limited use requires review", "not adequate without revision")
)

write.csv(
  overall_review,
  file.path(tables_dir, "r_validation_overall_review.csv"),
  row.names = FALSE
)

write.csv(
  register,
  file.path(tables_dir, "r_validation_review_queue.csv"),
  row.names = FALSE
)

png(file.path(figures_dir, "r_validation_residuals.png"), width = 1000, height = 700)

plot(
  errors$time,
  errors$residual,
  type = "b",
  xlab = "Time",
  ylab = "Residual",
  main = "Validation Residual Diagnostics"
)
abline(h = 0, lty = 2)
grid()

dev.off()

print(overall_review)
print(scenario_summary)
print(register)

The R layer supports model assessment by preserving overall diagnostics, scenario-specific summaries, and review priorities. It keeps the validation judgment tied to evidence rather than a vague approval label.

Back to top ↑

Haskell Workflow: Typed Validation Records

Haskell is useful here because validation concepts should remain distinct. Verification is not calibration. Calibration is not validation. A diagnostic metric is not a decision-use authorization.

{-# OPTIONS_GHC -Wall #-}

module Main where

data ValidationLayer
  = ConceptualValidity
  | Verification
  | EvidenceQuality
  | Diagnostics
  | Generalization
  | UncertaintyReview
  | DecisionSupport
  | Governance
  deriving (Eq, Show)

data ReviewStatus
  = Active
  | RequiresReview
  | RequiresValidation
  | RequiresUncertaintyCheck
  | Revise
  deriving (Eq, Show)

data ValidationRecord = ValidationRecord
  { key :: String
  , layer :: ValidationLayer
  , modelingRole :: String
  , assessmentFocus :: String
  , status :: ReviewStatus
  } deriving (Eq, Show)

validationRegister :: [ValidationRecord]
validationRegister =
  [ ValidationRecord
      "conceptual_validity"
      ConceptualValidity
      "Reviews structure, assumptions, boundaries, and purpose."
      "Model-system fit."
      RequiresReview
  , ValidationRecord
      "implementation_verification"
      Verification
      "Checks that code implements the model specification."
      "Implementation correctness."
      Active
  , ValidationRecord
      "data_validation"
      EvidenceQuality
      "Reviews observations, units, provenance, and alignment."
      "Evidence reliability."
      RequiresReview
  , ValidationRecord
      "residual_diagnostics"
      Diagnostics
      "Examines residuals, bias, and error patterns."
      "Systematic model error."
      Active
  , ValidationRecord
      "uncertainty_review"
      UncertaintyReview
      "Reviews sensitivity, robustness, and uncertainty."
      "Decision-changing uncertainty."
      RequiresUncertaintyCheck
  , ValidationRecord
      "fitness_for_purpose"
      DecisionSupport
      "Assesses adequacy for intended use."
      "Purpose-specific credibility."
      RequiresValidation
  ]

needsReview :: ValidationRecord -> Bool
needsReview item =
  case status item of
    Active -> False
    _ -> True

main :: IO ()
main = do
  putStrLn "Typed validation records:"
  mapM_ print validationRegister

  putStrLn "\nValidation records requiring review:"
  mapM_ print (filter needsReview validationRegister)

This typed layer supports validation governance by keeping conceptual validity, verification, evidence quality, diagnostics, uncertainty, and decision-support review conceptually separate.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It contains article-specific code, data, documentation, notebooks, schemas, and generated outputs for validation registers, model assessment diagnostics, residual analysis, scenario-level error summaries, fitness-for-purpose review, typed Haskell validation records, uncertainty review, and responsible decision-support workflows.

Back to top ↑

A Practical Method for Validation and Model Assessment

Validation should be planned as an evidence workflow, not added as a vague final statement. The method below keeps validation tied to purpose, evidence, diagnostics, uncertainty, and decision use.

This method prevents validation from becoming a rubber stamp. It turns model credibility into a reviewable evidence trail.

Back to top ↑

Common Pitfalls

Model validation can fail when it is treated as a formality rather than a serious assessment of credibility.

• Confusing fit with validation: treating calibration performance as proof of model credibility.
• Ignoring verification: assessing outputs before confirming that the model was implemented correctly.
• Using weak validation data: comparing against observations that are poorly aligned, biased, or undocumented.
• Reporting one metric only: hiding error patterns behind a single average score.
• No out-of-sample test: failing to assess generalization beyond calibration data.
• No benchmark comparison: accepting complexity without comparing simpler alternatives.
• Ignoring uncertainty: presenting validation as certainty rather than conditional evidence.
• Ignoring decision consequences: using the same validation standard for low-stakes and high-stakes uses.
• Overgeneralizing validation: claiming the model is valid without specifying purpose, scope, and limits.
• No governance record: leaving validation judgments undocumented and hard to review.

These pitfalls can be reduced through validation planning, verification tests, independent evidence, residual diagnostics, uncertainty analysis, benchmark comparison, fitness-for-purpose statements, and transparent use limits.

Back to top ↑

Conclusion: Validation Is Conditional Trust

Validation and model assessment ask whether a mathematical model is credible enough for its intended purpose. They do not make a model perfect. They make its evidence, uncertainty, and limits visible.

A model can be calibrated without being validated. It can be verified without being conceptually appropriate. It can perform well on average while failing in consequential cases. It can be useful for one purpose and dangerous for another.

Responsible validation therefore requires multiple forms of evidence: conceptual review, implementation verification, data validation, residual diagnostics, out-of-sample testing, benchmark comparison, uncertainty assessment, robustness analysis, and decision-use review.

Used well, validation protects model users from false certainty. It helps analysts distinguish useful models from misleading ones, communicate confidence honestly, and support accountable decisions. Validation is not a declaration of absolute truth. It is a disciplined judgment about conditional trust.

Back to top ↑

Related Articles

• What Is Mathematical Modeling?
• Model Purpose: Explanation, Prediction, Control, and Decision Support
• Calibration, Estimation, and Parameter Fitting
• Model Repositories, Data, and Reproducible Research
• Model Comparison and Selection
• Overfitting, Underfitting, and Model Generalization
• Diagnostics, Residuals, and Model Error
• Sensitivity Analysis and Robustness
• Uncertainty in Mathematical Models
• Model Interpretation and Decision-Making

Back to top ↑

Further Reading

• Oberkampf, W.L. and Roy, C.J. (2010) Verification and Validation in Scientific Computing. Cambridge: Cambridge University Press.
• National Research Council (2012) Assessing the Reliability of Complex Models: Mathematical and Statistical Foundations of Verification, Validation, and Uncertainty Quantification. Washington, DC: National Academies Press.
• Saltelli, A. et al. (2008) Global Sensitivity Analysis: The Primer. Chichester: Wiley.
• Burnham, K.P. and Anderson, D.R. (2002) Model Selection and Multimodel Inference: A Practical Information-Theoretic Approach. 2nd edn. New York: Springer.
• Box, G.E.P., Hunter, J.S. and Hunter, W.G. (2005) Statistics for Experimenters: Design, Innovation, and Discovery. 2nd edn. Hoboken, NJ: Wiley.
• Hastie, T., Tibshirani, R. and Friedman, J. (2009) The Elements of Statistical Learning. 2nd edn. New York: Springer.
• Gelman, A. et al. (2013) Bayesian Data Analysis. 3rd edn. Boca Raton, FL: CRC Press.
• Rykiel, E.J. (1996) ‘Testing ecological models: The meaning of validation’, Ecological Modelling, 90(3), pp. 229–244.
• Carson, J.S. (2002) ‘Model verification and validation’, Proceedings of the Winter Simulation Conference, pp. 52–58.
• Sargent, R.G. (2013) ‘Verification and validation of simulation models’, Journal of Simulation, 7(1), pp. 12–24.

Back to top ↑

References

• Box, G.E.P., Hunter, J.S. and Hunter, W.G. (2005) Statistics for Experimenters: Design, Innovation, and Discovery. 2nd edn. Hoboken, NJ: Wiley.
• Burnham, K.P. and Anderson, D.R. (2002) Model Selection and Multimodel Inference: A Practical Information-Theoretic Approach. 2nd edn. New York: Springer.
• Carson, J.S. (2002) ‘Model verification and validation’, Proceedings of the Winter Simulation Conference, pp. 52–58.
• Gelman, A. et al. (2013) Bayesian Data Analysis. 3rd edn. Boca Raton, FL: CRC Press.
• Hastie, T., Tibshirani, R. and Friedman, J. (2009) The Elements of Statistical Learning. 2nd edn. New York: Springer.
• National Research Council (2012) Assessing the Reliability of Complex Models: Mathematical and Statistical Foundations of Verification, Validation, and Uncertainty Quantification. Washington, DC: National Academies Press.
• Oberkampf, W.L. and Roy, C.J. (2010) Verification and Validation in Scientific Computing. Cambridge: Cambridge University Press.
• Rykiel, E.J. (1996) ‘Testing ecological models: The meaning of validation’, Ecological Modelling, 90(3), pp. 229–244.
• Saltelli, A. et al. (2008) Global Sensitivity Analysis: The Primer. Chichester: Wiley.
• Sargent, R.G. (2013) ‘Verification and validation of simulation models’, Journal of Simulation, 7(1), pp. 12–24.

Back to top ↑