Verification¶

Version: v3 · 2026-09-19 · History
Prime #: 1312
Domain group: Applied Sciences & Engineering
Origin domain: Engineering & Design (beyond software)
Also from: Experimental Design & Statistics, Mathematics, Computer Science & Software Engineering, Philosophy
Aliases: Conformance Check, Specification Check, Verification Discipline

Core Idea¶

Verification is the structured checking that a claim, artifact, process, or output conforms to a specified criterion, rule, requirement, or evidence standard. It asks "does this object satisfy the stated specification?" — a disciplined comparison against a fixed reference, producing accept, reject, or uncertain. The core commitment is conformance to a stated criterion, not the broader question of whether the criterion itself is the right one for the underlying purpose (that's validation). Verification is "are we building it right"; validation is "are we building the right thing." Boehm's distinction is the canonical articulation.

How would you explain it like I'm…

Did we build it right?

Imagine you're following a recipe to bake cookies. Verification is checking each step: did you put in the right amount of sugar? Did you bake for the right time? It doesn't ask whether cookies were the best choice for dessert — it just checks if you followed the recipe correctly.

Checking against the plan

Verification is checking whether something was built the way it was supposed to be built. If the plan says "put in two cups of flour," verification looks at whether you actually put in two cups. It does NOT ask whether the plan itself was a good plan — that's a different job called validation. So a robot can be perfectly verified (every part matches the blueprint) but still flop in the real world if the blueprint asked for the wrong thing.

Spec-conformance checking

Verification is the structural process of checking that an object conforms to its specification, through a defined procedure that yields evidence and a verdict: accept, reject, or qualified accept. The object can be a manufactured part, a piece of software, a mathematical proof, a scientific result, or an institutional practice. The specification is whatever fixed criterion governs it. Barry Boehm (1984) formalized the distinction in software engineering: verification asks 'are we building this RIGHT?' against a stated spec, while its partner validation asks 'are we building the RIGHT thing?' A correctly verified artifact can still fail in the field if the spec it satisfies does not match the real need.

Verification is the structural process of checking that an object conforms to its specification via a defined procedure that yields evidence and a verdict — accept, reject, or qualified — a formulation Boehm (1984) introduced as the *V&V* (Verification & Validation) foundation in software engineering. The object can be a manufactured part, a software artifact, a mathematical derivation, a scientific result, or an institutional practice; the specification is whatever fixed criterion has been declared to govern it; the procedure is the test, audit, proof-check, measurement, or inspection that produces evidence; and the verdict closes the loop. The defining commitment is that the criterion is *taken as given*: verification answers 'are we building this *right*?' against a stated spec, and explicitly does not ask whether the spec itself captures the underlying purpose — that is the work of *validation*, the other half of the canonical V&V dyad. A correctly verified artifact can still fail in the field because the specification it satisfies does not match real-world intent.

Broad Use¶

Engineering / manufacturing: quality control — does the manufactured part meet dimensional tolerances and material spec?
Software: unit tests, integration tests, type checking, model checking, formal verification of correctness against specification.
Mathematics / formal systems: proof checking, verification of a derivation against the rules of a formal system.
Science: reproducibility and replicability as independent verification of a finding's conformance to its reported method/result.
Law / compliance / accreditation: audit against a regulatory or standards regime.
Institutional review: accreditation reviews, certification audits, conformance assessments against a published standard.

Clarity¶

Verification sharpens a distinction that everyday language blurs: the difference between checking that an artifact meets its stated specification and checking that the specification itself is the right one. The first is verification; the second is validation. A formally verified program can still fail in the field because the specification it satisfies does not capture the actual user need. A manufactured part can pass every dimensional check and still be the wrong part. Verification is the conformance concept — fixed criterion, disciplined comparison, accept/reject/uncertain — and naming it lets the analyst separate "the check passed" from "the thing actually works for its purpose." This is the load-bearing V&V distinction (Boehm) and the reason the prime is needed alongside Validation.

Manages Complexity¶

Verification decomposes a "did this pass review?" situation into five named roles: an object (the artifact, claim, output, or derivation being checked), a specification or criterion (the fixed reference against which the object is compared), a checking procedure (test, audit, proof, measurement, inspection), evidence or observations (the result of running the procedure), and an accept/reject/uncertain result. Once those five roles are visible, an opaque "review" becomes a structured workflow with leverage points: is the specification crisp enough to check against? Is the procedure repeatable? Is the evidence chain traceable? Is the result well-typed (accept/reject/uncertain — not a vague summary)? The five-role schema recurs identically across a software test suite, a manufacturing QC line, a mathematical proof check, and a regulatory audit. Naming the roles is what converts a tangled review process into a graph the analyst can audit, redesign, or automate.

Abstract Reasoning¶

The defining structural commitment of verification is that the criterion is taken as given — the work is conformance-checking, not criterion-design. That asymmetry is what the prime enables the analyst to reason about. From it falls out a family of counterfactuals: if the criterion were different, would this object still pass? (sensitivity of the check); if the procedure were stricter, would more objects fail? (test power); if the object were perturbed in a known way, would the check catch it? (coverage). It also enables the V&V split-reasoning move: separate "the spec is wrong" failures (validation problem) from "the artifact doesn't meet the spec" failures (verification problem). That split is load-bearing across engineering — it determines which team owns the defect and what kind of fix is needed. Without the verification prime, the diagnosis collapses into a single "it failed review" verdict that hides which half of V&V is actually broken.

Knowledge Transfer¶

The conformance-to-stated-criterion pattern travels intact across substrates that share no surface vocabulary. A mathematician checking a proof against the inference rules of a formal system, a manufacturing inspector checking a part against engineering tolerances, a software engineer running a unit test against a function contract, a scientist running a replication study against a published protocol, and a compliance auditor checking a firm against a regulatory standard are all running the same five-role pattern: object, criterion, procedure, evidence, verdict. The mathematics case is the cleanest demonstration of substrate independence — no physical artifact, no human institution, no measurement instrument, yet the verification pattern is present in full. That rules out the suspicion that "verification" is an engineering specialty; it is a generic checking-against-fixed-reference relation that engineering happens to have given its most explicit vocabulary. The same transfer goes the other way: a software engineer reading about scientific replication recognizes a test-suite problem; a scientist reading about formal verification recognizes a stricter version of replication.

Example¶

Consider a structural-engineering firm that has manufactured a steel beam intended for a bridge. The object is the beam. The specification is the engineering drawing plus material standard: dimensional tolerances, yield strength, weld-quality grade. The checking procedure is a sequence — caliper measurement for dimensions, tensile test on a coupon for yield strength, ultrasonic inspection for weld integrity. The Evidence is the recorded measurements and test reports. The verdict is accept/reject/uncertain against each criterion, rolled up to a single conformance decision. Crucially, this verification can succeed while validation fails: the beam may pass every dimensional and material check and still be the wrong beam for the bridge — if the original specification underestimated the actual load, the beam is verified-but-invalid. That is the V&V distinction made concrete. The same five-role structure transfers without change to a mathematician checking a proof (object = derivation, criterion = inference rules, procedure = step-by-step rule-application, evidence = each step's justification, verdict = valid/invalid/incomplete) and to a software type-checker (object = program, criterion = type system, procedure = inference algorithm, evidence = derivation tree, verdict = well-typed/ill-typed/unknown).

Relationships to Other Abstractions¶

Current abstraction Verification Prime

Parents (1) — more general patterns this builds on

Verification is a kind of Evaluation Prime

Verification is the strict species of Evaluation whose criterion is a stated specification and whose defined checking procedure yields evidence and a conformance verdict.

Children (39) — more specific cases that build on this

Bechdel test Domain-specific is a kind of Verification

The Bechdel–Wallace test is a bounded verification procedure.
Costly state verification Domain-specific is a kind of Verification

It remains its own entry because its identity is fixed by the entrepreneur and financier, project return distribution and private observation, report and transfer schedule, verification technology and cost, commitment and enforcement, incentive-compatibility and participation constraints, audit region, expected surplus objective and conditions yielding a standard debt contract.
Dry Run (Testing) Domain-specific is a kind of Verification

Verification is the strict parent because a dry run applies a defined procedure to collect evidence that an intended operation matches scope, plan, and preconditions.
Existential theory of the reals Domain-specific is a kind of Verification

It remains its own entry because its identity is fixed by the real variables and coefficient encoding, existential quantifier block, quantifier-free Boolean combination, polynomial equations strict or weak inequalities, real-number interpretation, satisfiability or semialgebraic nonemptiness, reduction model, decision algorithm and complexity bounds, ETR-hardness and completeness and distinction from full first-order theory of real closed fields.
FNP (complexity) Domain-specific is a kind of Verification

It remains its own entry because its identity is fixed by the binary alphabet or encoding, instance x and witness y, polynomial balance bound on witness length, deterministic polynomial-time verification predicate, multivalued output relation, induced NP language, reduction convention, FNP-completeness, distinction between finding and verifying and totality or uniqueness subclasses.

▸ Show 34 more

Formal Verification Domain-specific is a kind of Verification
Formal verification is verification specialized to a machine-checkable mathematical derivation over every input in a formally specified scope.
Hautus lemma Domain-specific is a kind of Verification
What makes it its own entry: the domain-specific identity determined by the system matrices, field, eigenvalue range, and exact full-rank condition corresponding to the claimed control property are stated and equivalent.
Interactive proof system Domain-specific is a kind of Verification
The system verifies claims through structured challenge and response.
Kalman–Yakubovich–Popov lemma Domain-specific is a kind of Verification
It remains its own entry because its identity is fixed by the continuous or discrete linear time-invariant state-space matrices, stability and controllability or minimality assumptions, frequency-domain transfer expression and positivity inequality, symmetric matrix P and auxiliary factors, Lyapunov or LMI relation, strict or nonstrict version, storage function and dissipativity or positive-real interpretation and equivalence directions.
Kline sphere characterization Domain-specific is a kind of Verification
It remains its own entry because its identity is fixed by the compact connected locally connected metric space or continuum and theorem-version hypotheses, simple closed curves, complement and exactly two components, pairs of points and connected complement, nondegeneracy and local conditions, conclusion homeomorphic to S2 and relationship to Jordan curve theorem and alternative characterizations.
Polynomial identity testing Domain-specific is a kind of Verification
It remains its own entry because its identity is fixed by the field, variables, degree bound, representation class, black-box or white-box access, identity criterion, randomness, error probability, and computational cost.
Process validation Domain-specific is a kind of Verification
It remains its own entry because its identity is fixed by the product and intended use, process boundary and flow, critical quality attributes and parameters, risk assessment, equipment and methods, acceptance criteria, qualification evidence, sampling and statistics, deviations, change control and continued monitoring.
Property-Based Testing Domain-specific is a kind of Verification
Property-based testing is verification specialized to checking a stated software invariant against inputs drawn by a typed generator.
Resultant Domain-specific is a kind of Verification
It remains its own entry because its identity is fixed by the coefficient ring or field and two univariate polynomials, declared degrees and leading coefficients, common root in an algebraic closure or common factor, Sylvester matrix or product-over-roots construction, determinant formula, sign and scaling convention, zero criterion, discriminant specialization and elimination and computational uses.
Runtime Verification Domain-specific is a kind of Verification
Runtime verification checks an observed system run against a stated correctness property and yields a trace-relative verdict.
Score test Domain-specific is a kind of Verification
It remains its own entry because its identity is fixed by the parametric likelihood and data, parameter vector and null constraints, constrained maximum-likelihood estimate, score vector, observed or expected Fisher information and nuisance adjustment, quadratic statistic and degrees of freedom, asymptotic null distribution, regularity and boundary conditions, one- or two-sided decision and relation to Wald and likelihood-ratio tests.
Seaworthiness (law) Domain-specific is a kind of Verification
It remains its own entry because its identity is fixed by the jurisdiction and governing instrument, vessel voyage and cargo, responsible party and beneficiary, relevant attachment time, structural equipment crewing and documentation conditions, absolute warranty or due-diligence standard, known hazards and causation, inspection evidence and remedies defenses and detention consequences.
Semantic analysis (compilers) Domain-specific is a kind of Verification
It remains its own entry because its identity is fixed by the source language and parsed syntax tree, symbol tables and scopes, declarations and bindings, type and compatibility rules, overload or access resolution, contextual constraints, diagnostics and annotated tree or intermediate representation.
Semantic theory of truth Domain-specific is a kind of Verification
It remains its own entry because its identity is fixed by object language, metalanguage, interpretation, satisfaction recursion, quotation or coding, compositional clauses, expressive-strength separation, and adequacy criterion.
Separating words problem Domain-specific is a kind of Verification
What makes it its own entry: the domain-specific identity determined by the resulting deterministic finite automaton yields different acceptance values for the two declared words and no smaller DFA under the same conventions does so.
Testing hypotheses suggested by the data Domain-specific is a kind of Verification
It remains its own entry because its identity is fixed by the dataset and analysis population, exploratory search space and analyst degrees of freedom, selected hypothesis, selection criterion, test statistic and null model, reuse of observations, nominal and actual error rates, multiplicity or selective-inference adjustment, preregistration sample splitting or replication remedy and reporting of exploratory status.
Witness set Domain-specific is a kind of Verification
What makes it its own entry: the domain-specific identity determined by for every other concept in the declared class there exists at least one selected input on which its value differs from the target's value.
Data Integrity Prime is a kind of Verification
Data Integrity is a kind of verification: checksums, signatures, and audits confirm conformance to the data's intended specification.
Due diligence Prime is a kind of Verification
The accepted reference-grade review places Due diligence under Verification because the child instantiates or depends on the parent's broader structure while retaining its own constitutive identity.
Hypothesis Testing (Null vs. Alternative) Prime is a kind of Verification
Hypothesis testing is a specific kind of verification, checking sample evidence against a pre-specified null with controlled error rates.
Proof of impossibility Prime is a kind of Verification
The accepted reference-grade review places Proof of impossibility under Verification because the child instantiates or depends on the parent's broader structure while retaining its own constitutive identity.
Quality Control Prime is a kind of Verification
Quality control is a specialization of verification in which the conformance check operates as a release gate against manufacturing-style tolerance specs.
Reproducibility & Replicability Prime is a kind of Verification
Reproducibility and replicability are a specialization of verification in which the conformance check is repeating the study to confirm the finding.
Zero Knowledge Proof Prime is a kind of Verification
ZKP fills verification's five-role schema (claim/protocol/challenge-response/transcript/verdict) with added zero-knowledgeness — a species of verification protocol, not a component of it.
Digital signature Domain-specific is part of Verification
A Digital Signature strictly contains Verification as the public procedure that checks the mark-message-key relation and returns valid or invalid.
Extended Static Checking Domain-specific is part of Verification
a defined procedure checks an artifact against explicit obligations.
Van Halen Test Domain-specific presupposes Verification
The marker must first be verified against its stated instruction before it can serve as a compliance-triage signal.
Verifiable Computing Domain-specific presupposes Verification
Verifiable Computing presupposes Verification because the client accepts delegated output only by checking accompanying evidence against the computation specification.
Certification Prime presupposes Verification
Certification = a verification procedure PACKAGED into a portable, third-party-attested token; it presupposes (is built on) the verification work it wraps.
Confidence Annotation Prime presupposes, typical Verification
A graded warrant marker summarizing how-much-to-trust once weighing is done; presupposes the verification/evidence-weighing whose verdict it compresses into a portable, separable label.
Time-Of-Check To Time-Of-Use Flaw Prime presupposes Verification
Time-Of-Check To Time-Of-Use Flaw presupposes Verification, whose structure must already obtain for the child mechanism to be meaningful or operational.
Triangulation Prime presupposes Verification
Triangulation presupposes verification because cross-checking against multiple independent sources is a discipline for confirming conformance to a specification.
Validation Prime presupposes Verification
Validation presupposes verification because both rest on checking an artifact against a stated criterion via a procedure yielding a verdict.
Casting out nines Domain-specific is a decomposition of Verification
Casting out nines is an arithmetic verification procedure for detecting some calculation errors.

Hierarchy path (1) — routes to 1 parentless root

Verification → Evaluation → Comparison → Self Checking

Not to Be Confused With¶

Not Validation: validation asks whether the model/process/output measures or achieves the intended real-world purpose — whether the spec is the right spec. Verification asks only whether the object meets the spec as stated. A correct verification of a wrong specification yields a verified-but-invalid artifact. Classic V&V dyad.
Not Monitoring: monitoring observes a system's state over time to detect deviation from expected behavior. Verification evaluates against a static specification at a checkpoint, not continuously. (Note: Quality Control was committed → monitoring R14 — but it presupposes a verification step against spec; multi-parent fine.)
Not Traceability: traceability supplies the evidence chain — the documented history that enables verification. Traceability is what you check; verification is the act of checking.
Not Provenance: provenance is the origin/custody record; it can serve as evidence in verification.
Not Falsifiability: falsifiability is a property of a hypothesis (its openness to refuting evidence). Verification is the act of checking against criteria, which may be (but need not be) Popperian.

Notes¶

The V&V pair (validation + verification) is canonical in engineering and quality literature; the catalog has validation but not verification, which left edges in the verification family awkwardly parented (e.g., reproducibility_replicability → validation committed R14 explicitly because no verification prime existed).

If accepted, consider whether Quality Control should gain verification as a 2^nd parent alongside monitoring (the spec-check half + the continuous-observation half are both real components of QC).