Validation

Prime #

548

Origin domain

Statistics & Experimental Design

Subdomain

experimental design → Statistics & Experimental Design

Also from

Computer Science & Software Engineering, Philosophy, Engineering & Design

Aliases

Validity, Validity Theory

Core Idea

Checking that an artifact, claim, or model satisfies its intended specification or correctly represents the phenomenon it claims to describe. Validation answers "are we building the right thing?" — it is a fitness-for-purpose assessment distinct from verification (specification correctness) and falsification (logical refutation).

How would you explain it like I'm…

Did We Build the Right Thing?

Imagine you build a paper airplane to throw far. Validation is when you actually throw it and see if it flies far. You're not checking if you folded it neatly — you're checking if it does the thing you wanted it to do. If it nosedives, it failed validation, even if the folds were perfect.

Building the right thing

Validation is asking, "Did we build the right thing?" Imagine you build a robot that's supposed to fetch your shoes. Validation is testing whether it actually helps you get your shoes when you need them — not just whether the wheels spin and the arm moves (that's a different kind of check, called verification). A product can be built perfectly and still fail validation if it doesn't solve the real problem. That's why engineers, doctors, and scientists test things in real situations before shipping them.

Fitness-for-purpose check

Validation is the structured process of confirming that a model, design, system, or claim actually satisfies its intended purpose and solves the right problem in its real operating context. Software engineer Barry Boehm framed it with two questions: validation asks "are we building the right thing?" while verification asks "are we building the thing right?" A self-driving car can perfectly meet every technical specification (verification passes) and still fail validation if it can't actually handle real streets. The idea originated in software engineering but recurs everywhere — drug trials, machine learning model evaluation, psychometric tests, product launches. It surfaces the gap between what designers intended and what the artifact actually does in deployment, catching expensive failures before they happen in the wild.

 

Validation is the structured process of confirming that a model, design, system, or claim satisfies its intended specification and solves the right problem in its actual operational context (Boehm, 1981). It is fundamentally a fitness-for-purpose assessment, answering "are we building the right thing?" The construct is distinct from verification (specification correctness: "are we building the thing right?") and from falsification (logical refutation: "is this claim disprovable?"), a distinction Boehm (1984) crisply articulated in his V-model of software engineering. Validation requires evidence that the artifact, in its real deployment context, produces outcomes aligned with the underlying purpose for which it was commissioned — not merely outcomes consistent with the written specification. The distinction originates in software engineering but recurs across experimental design, regulatory affairs, clinical medicine (where a drug must validate against patient outcomes, not just lab markers), machine learning (where models must validate on out-of-distribution data and downstream tasks), psychometrics (construct validity), and commercial product development. Validation surfaces the gap between design intent and actual behavior, reducing costly late-stage failures in which artifacts fail in deployment despite meeting all stated technical specifications.

Broad Use

• Science & statistics: cross-validation in ML/statistics, model validation against empirical data, replication studies.
• Software engineering: input validation, integration testing, schema validation, data consistency checks.
• Engineering design: validation against requirements through testing and demonstration; paired with verification in the V-model lifecycle.
• Philosophy: logical validity (argument-form correctness), truth-conditional analysis, semantic coherence.
• Regulatory & manufacturing: FDA/EMA validation for clinical protocols, manufacturing processes, and biotech documentation.
• Quality assurance: user acceptance testing, conformance to stakeholder needs, real-world performance validation.

Clarity

Names the moment when an artifact or claim is confirmed to work as intended in its actual context. Surfaces the distinction between building something correctly (verification) and building the correct thing (validation), reducing costly late-stage failures.

Manages Complexity

Frames real-world fit as a testable problem: define the specification or intended behavior, design validation procedures, run experiments or tests, and interpret results. Bounds scope to what demonstrates fitness-for-purpose rather than abstract correctness.

Abstract Reasoning

Encourages thinking about the gap between design intent and actual behavior, counterfactual scenarios ("what if we had built X instead?"), and success criteria independent of internal correctness. Promotes questioning what counts as evidence of fitness.

Knowledge Transfer

The same validation pattern recurs in pharmaceutical trials, aircraft certification, software acceptance testing, scientific peer review, and architectural design review. Tools from one domain (randomization, blinding, benchmarking, acceptance criteria) transfer across disciplinary boundaries.

Example

A pharmaceutical company develops a new antihypertensive drug: verification confirms the synthetic pathway produces the intended chemical structure; validation runs clinical trials to confirm it lowers blood pressure safely in target patients. A software team builds an authentication system: verification confirms the code matches specifications; validation tests it against real attack vectors and user workflows. Both require moving beyond design intent to real-world evidence.

Relationships to Other Primes

Parents (2) — more general patterns this builds on

• Validation presupposes Feedback — Validation presupposes Feedback: confirming fitness for purpose requires routing real-world observations back to test the artifact against intended use.
• Validation presupposes Verification — Validation presupposes verification because both rest on checking an artifact against a stated criterion via a procedure yielding a verdict.

Path to root: Validation → Feedback

Not to Be Confused With

• Validation is not Quality Control because Validation asks whether a product, process, or system correctly satisfies its intended purpose and user needs (does the right thing exist?), while Quality Control asks whether specifications and standards are met (does the thing meet the spec?); validation is about fitness for purpose, quality control is about conformance to specification.
• Validation is not Legitimacy because Validation is the technical or empirical verification that a system or result meets its requirements or performs its intended function, while Legitimacy is the normative acceptance by stakeholders that a system or authority has the right to exist or make binding decisions; validation is technical/empirical, legitimacy is normative/social.
• Validation is not Robustness because Validation confirms that a system performs correctly under its specified conditions and requirements, while Robustness is the capacity to maintain performance across a range of conditions or disturbances beyond the nominal design case; validation tests within specification, robustness tests beyond it.