Is verification the same as testing?

No. Testing examines executions; formal verification reasons about specified properties across a modeled scope.

Does verified mean useful?

Not necessarily. A precisely satisfied specification can still miss the user's need.

Can verification apply to AI-related systems?

Yes, for suitably specified components or models, but the claim must state what behavior and assumptions were covered.

AI Glossary / Graphs and symbolic AI / Intermediate

Verification

Definition

Verification is the process of checking whether a system satisfies specified requirements. In the formal-methods context used here, mathematical reasoning is applied to a program, circuit, or model to establish stated properties under explicit assumptions. The result concerns those properties and assumptions; it is not an unrestricted claim that the system is correct in every possible sense.

What it means

A specification states what must hold, such as a permitted output range or a relationship between inputs and outputs. Verification asks whether the implementation obeys that specification. Validation asks whether the specification and resulting system address the intended real-world need.
This distinction matters because a system can satisfy an incomplete requirement while still behaving undesirably. Formal verification can provide stronger coverage of a stated property than checking a few examples, but the scope depends on the modeled behavior, environment assumptions, and reasoning method. Testing and verification can support each other rather than serving as interchangeable labels.

How it works

Express the required behavior precisely. For a program component, this can include preconditions that must hold before execution, postconditions that must hold afterward, and invariants maintained during repeated operations. A verifier attempts to discharge the resulting proof obligations.
Some approaches reason deductively; others explore a formal state model. A failed proof attempt can indicate an actual defect, an inadequate specification, missing supporting facts, or a limitation of the tool. A counterexample should be checked against the model and assumptions. Successful verification should be reported with the exact property and scope rather than reduced to a vague “verified” badge.

Three practical examples

A software component can be checked to ensure that its returned index stays within an array's valid range under stated preconditions.
A hardware model can be checked against a logical property describing permitted signal combinations.
A planning controller can be analyzed for a specified state invariant, provided the model captures the transitions relevant to that claim.

Think of it this way

Think of checking a construction against a precise drawing and a list of measurable requirements. Passing those checks establishes agreement with the drawing, but the drawing might still omit a needed feature. The analogy is limited because formal verification relies on mathematical semantics and assumptions rather than physical inspection alone.

Worked example

Consider an original integer-valued function intended to clamp a requested quantity n into the interval from zero to a nonnegative capacity c. A first specification says only that the returned value r must satisfy 0 ≤ r ≤ c, assuming c ≥ 0.
An initial implementation returns c when n exceeds c and otherwise returns n. Try n = −3 and c = 5. The function returns −3, violating the lower bound. This concrete counterexample shows that handling the upper limit alone is insufficient when negative requests are allowed.
A corrected three-branch implementation returns zero when n < 0, returns c when n > c, and otherwise returns n. A manual proof of the range property follows by cases.
In the first branch, r = 0, and c ≥ 0 establishes 0 ≤ r ≤ c. In the second branch, r = c, so the same precondition establishes the bounds. In the final branch, the failed earlier conditions imply 0 ≤ n ≤ c, and r = n therefore satisfies them. These cases cover every integer n.
However, another implementation that always returns zero also satisfies the original range property whenever c ≥ 0. It is usually not the intended clamp behavior: for n = 3 and c = 5, it returns zero instead of three.
Strengthen the specification to state the complete input-output relationship: negative n produces zero; n between zero and c is preserved; and n above c produces c. The corrected three-branch implementation meets those conditions, while the always-zero implementation fails the middle case.
This example exposes two different issues: an implementation can violate a valid property, and a property can be too weak to capture the intended behavior. The reasoning is a manual proof over mathematical integers, not a claim that a verification tool was run or that every machine-integer implementation has been checked.

Illustrative case study

In a fictional software project, a team asks for a proof that a configuration helper never returns an out-of-range quantity. Reviewers notice that the requirement does not state what should happen for an already valid input.
They add the preservation requirement, review the assumptions about numeric types, and then verify the revised component. The fictional case illustrates why specification review is part of the work. It does not describe a deployed system or an actual completed machine-checked proof.

Common misconceptions and mistakes

Verification does not prove requirements that were never stated. It also does not automatically cover deployment configuration, external services, hardware faults, or behavior excluded by the model.
Do not interpret every failed proof attempt as evidence of a real bug; the tool may need a stronger invariant or other supporting information. Conversely, do not dismiss a counterexample merely because ordinary tests did not find it. Finally, a proof under a precondition is only relevant when callers actually satisfy that precondition.

Business use

The concept helps teams make correctness claims precise and reviewable. It is useful when a narrowly defined property matters enough to justify explicit modeling and proof work.
Identify the component, property, assumptions, and excluded behavior. Keep the specification understandable to the people responsible for the requirement. Record the evidence produced and the tool or reasoning method used. When implementation or assumptions change, reassess whether the earlier argument still applies instead of carrying forward a general verification claim unchanged.

Check your understanding

Why does an always-zero implementation pass the first clamp specification?

Answer: The specification only requires a result inside the interval. It does not require preserving valid inputs or returning the upper limit for excessive ones.

Related terms

Precondition
Model checking
Theorem proving
Validation
Formal methods
Specification
Postcondition
Invariant
Counterexample

Learn next

Next, remove the assumption c ≥ 0. If c is negative, no value can satisfy both 0 ≤ r and r ≤ c. Explain why this is a specification-feasibility problem and why an implementation change alone cannot satisfy those contradictory bounds.

Sources

Primary sources: Dafny official tutorial, specifications, preconditions, and postconditions: https://dafny.org/dafny/OnlineTutorial/guide ; AIMA original verification context: https://raw.githubusercontent.com/aimacode/aima-glossary/master/sentences.txt . The clamp function and manual case proof are original.

Previous: Verifiable computing Next: Verification and validation