Verification

Prime #

None

Origin domain

Engineering & Design

Also from

Experimental Design & Statistics, Mathematics, Computer Science & Software Engineering, Philosophy

Aliases

Conformance Check, Specification Check

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 Primes

Foundational — no parent edges in the catalog.

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

• Data Integrity is a kind of Verification — Data Integrity is a kind of verification: checksums, signatures, and audits confirm conformance to the data's intended specification.
• Hypothesis Testing (Null vs. Alternative) 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.
• Quality Control 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 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.
• Triangulation presupposes Verification — Triangulation presupposes verification because cross-checking against multiple independent sources is a discipline for confirming conformance to a specification.

▸ Show 1 more

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). With verification in place, those edges can be revisited. ChatGPT Pro's R16 pass independently surfaced this gap and proposed the same slug. 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).