One-sentence answer: Verification works by comparing a claim, product or result against explicit requirements using evidence that another competent checker can inspect or reconstruct, while keeping verification separate from the deeper question of whether the thing is useful for its intended purpose.
“It works” is not a verification statement. Neither is “I checked it.” Verification begins when the thing being checked, the requirement it must satisfy, the method of checking and the evidence produced are all explicit enough for someone else to audit.
Verification is confidence built from traceable comparison, not confidence borrowed from the person who built the thing.
Quick Read: the causal chain
CLAIM / REQUIREMENT → ACCEPTANCE CRITERION → TEST OR CHECK METHOD → CONTROLLED INPUTS → OBSERVATION → EVIDENCE → PASS / FAIL / EXCEPTION → INDEPENDENT RECONSTRUCTION → TRACEABILITY → CORRECTION → RE-VERIFICATION
1. Verification needs something explicit to verify
A vague requirement cannot be verified cleanly. “The system should be fast” leaves the checker guessing. “The system shall return a valid response within two seconds for 95% of requests under the specified load profile” provides a target, a metric, a threshold and conditions.
NASA’s current systems-engineering guidance defines product verification as proof of compliance with requirements or specifications and distinguishes it from validation, which asks whether the product accomplishes the intended purpose and stakeholder expectations.
This creates the foundational distinction:
| Verification | Did we build it according to the stated requirements? |
|---|---|
| Validation | Did we build the right thing for the intended use and receiver? |
A product can pass every stated requirement and still fail the user if the requirements themselves were wrong or incomplete.
2. Requirements need identifiers and traceability
Serious verification systems do not rely on memory. Requirements receive identifiers. Each requirement is linked to one or more verification methods and evidence records. NASA’s Systems Engineering Handbook includes a Requirements Verification Matrix for exactly this reason: every “shall” should have a planned method showing how compliance will be demonstrated.
The chain looks like this:
REQUIREMENT ID → SOURCE → VERIFICATION METHOD → TEST/ANALYSIS/INSPECTION/DEMONSTRATION → RESULT → EVIDENCE LOCATION → EXCEPTION / WAIVER → APPROVAL STATE
Traceability lets later readers answer a vital question: What exactly gives us the right to say this requirement passed?
3. Verification method must fit the claim
Different claims require different evidence. NASA guidance commonly separates verification into methods such as analysis, inspection, demonstration and test.
| Method | What it does | Example |
|---|---|---|
| Inspection | Examines physical or documented characteristics. | Check dimensions, labels, configuration or required documentation. |
| Analysis | Uses calculations, models or data to demonstrate compliance. | Structural stress analysis against a requirement. |
| Demonstration | Shows that a function can be performed under specified conditions. | Demonstrate that an emergency release can be operated. |
| Test | Applies controlled inputs and measures outputs. | Load-test an API or vibration-test a component. |
| Formal proof / logical verification | Shows that a property follows from a formal model or specification. | Prove an algorithm preserves an invariant. |
None of these methods is automatically superior. A visual inspection cannot prove throughput under peak load. A simulation cannot substitute for a physical test when the unmodelled failure modes are exactly what matter. A formal proof can prove properties of a formal model while leaving assumptions about implementation or environment unresolved.
4. Pass/fail criteria should exist before the result is seen
If the acceptance threshold moves after the result arrives, verification becomes negotiation disguised as testing. Strong verification therefore predeclares:
- the requirement;
- the exact method;
- the operating conditions;
- the sample or test article;
- the threshold;
- allowed uncertainty;
- treatment of missing data;
- rules for exceptions and retries.
Unexpected results may justify changing the requirement or test method—but the change should be documented rather than quietly rewritten around the outcome.
At Singapore scale, a verification result becomes part of What Makes Singapore Work | The Learning Loop when a pass, failure or exception does more than close a checklist: the evidence is routed back into diagnosis, requirements, design or the next decision, with the change kept traceable. This page remains the general mechanism owner for verification.
5. Verification is only as good as its test coverage
Passing sampled tests does not prove universal correctness. A software system may pass normal traffic but fail under concurrency. A manufactured part may pass room-temperature testing but fail after thermal cycling. A student may solve familiar examples but fail an unfamiliar transfer question.
Verification should therefore expose the coverage envelope:
- which inputs were tested;
- which ranges were covered;
- which edge cases were included;
- which interfaces were exercised;
- which failure states were triggered;
- what was not tested;
- whether the environment matched deployment.
A pass outside its tested envelope is an inference, not a verified fact.
6. Verification should challenge shared assumptions
The same team, model, dataset and toolchain can reproduce the same mistake. Independence is valuable because it reduces correlated error.
An independent checker may use:
- a separate implementation;
- another instrument;
- another dataset;
- a blind review;
- a second calculation route;
- a separate test team;
- a different model or assumption set.
Independence does not guarantee correctness. It improves the chance that hidden shared assumptions will be exposed.
7. Verification ≠ reproduction ≠ replication ≠ validation
| Term | Main question |
|---|---|
| Verification | Does the artefact or result conform to stated requirements/specification? |
| Reproduction | Can the result be obtained again using the same data, code, method or artefacts? |
| Replication | Does an independent study or implementation obtain compatible findings under a new execution? |
| Validation | Does the system or model serve its intended real-world use? |
| Audit | Does the evidence, process or control system conform to an audit scope and criteria? |
These jobs overlap but should remain conceptually separate. Reproducing a wrong answer is still possible. Verification against a bad requirement is still possible. Validation can fail after verification passes.
8. Circular verification is not independent evidence
A system should not be considered verified merely because it checks itself using the same internal logic that produced the result.
Examples of circular assurance include:
- an AI answer “verifies” itself by asking the same model to review its output without external evidence;
- a spreadsheet checks a total using a formula derived from the same broken source cells;
- a simulation is validated only against synthetic data produced by the same model family;
- a manufacturer inspects only the dimension its own faulty gauge created.
Internal checking can be useful, but confidence rises when the verification path introduces independent evidence or a meaningfully different failure mode.
9. Verification needs uncertainty too
If a requirement says a dimension must be at least 10.00 mm, and the measured result is 10.01 mm with substantial measurement uncertainty, a naive pass/fail decision may be misleading.
Measurement and Uncertainty therefore sit underneath good verification. The evidence must be capable of distinguishing pass from fail at the required resolution.
10. Verification across a system is hierarchical
Components can pass individually while the integrated system fails. Interfaces create new failure modes.
A useful hierarchy is:
UNIT → COMPONENT → SUBSYSTEM → INTEGRATED SYSTEM → END-TO-END RECEIVER PATH
NASA guidance explicitly includes verification after integration because the assembled system can behave differently from its verified parts. End-to-end tests are especially important when timing, interfaces, power, data, human operation or environmental conditions interact.
11. Worked example: verifying an API
Suppose an API specification states that a request with a valid token and valid payload must return a specified JSON structure within two seconds under a defined load.
Verification could include:
- schema tests for required fields;
- authentication tests;
- boundary-value tests;
- invalid-input tests;
- latency tests under declared load;
- concurrency tests;
- version-compatibility tests;
- independent client implementations.
If all pass, the API may conform to the specification. That still does not prove the API solves the user’s actual problem, communicates the right meaning or is safe for every deployment. Those are validation, interoperability, security and domain-owner questions.
12. Worked example: verifying a student’s answer
A mathematics answer can be verified several ways:
- substitute the result back into the original equation;
- solve using a second method;
- estimate the expected magnitude;
- check dimensions or units where relevant;
- inspect whether all constraints were respected.
This is stronger than rereading the same working and hoping to notice the same error. Independent checking routes deliberately introduce different failure modes.
13. Verification across domains
| Domain | Verification question | Boundary |
|---|---|---|
| Engineering | Does the product meet specified requirements? | Passing requirements does not alone prove intended-use success. |
| Software | Does implementation conform to requirements and specified behaviour? | Tests cover finite cases unless stronger proof exists. |
| Science | Can procedures, calculations or results be independently checked? | Verification is not automatic proof of causal theory. |
| Education | Can an answer or skill be checked against criteria using an independent route? | One verified answer does not establish complete mastery. |
| Publishing | Do claims trace to sources and quotations/figures match originals? | Source existence does not prove source quality. |
| AI | Can outputs be checked against tools, sources, constraints and external tests? | Self-review by the same model is not independent world evidence. |
14. Common verification failures
| Failure | What goes wrong | Repair |
|---|---|---|
| Vague requirement | Checker cannot tell what pass means. | Make criterion measurable and traceable. |
| Test-after-result | Acceptance rule changes to fit outcome. | Predeclare method and threshold. |
| Coverage blindness | Passing sampled cases is treated as universal correctness. | Document coverage and untested envelope. |
| Circular assurance | The producing mechanism is also the only checker. | Add independent evidence or alternative method. |
| Component-only verification | Integrated interface failures remain unseen. | Verify subsystem and end-to-end paths. |
| Uncertainty ignored | Evidence cannot distinguish pass from fail reliably. | Include measurement/model uncertainty. |
| Verification=validation | Conformance is mistaken for usefulness. | Run intended-use validation separately. |
| Evidence without provenance | Result cannot be reconstructed. | Record source, version, configuration and time. |
15. Hostile test: give it to another checker
A strong verification packet should let another competent checker answer the same requirement question without relying on private knowledge held by the builder.
- What requirement is being checked?
- Where did the requirement come from?
- What counts as pass?
- Which method was used?
- What inputs and configuration were present?
- What evidence was recorded?
- What uncertainty applies?
- Which cases were not covered?
- Can another checker reproduce or independently confirm the result?
- What exception or failure would force re-verification?
16. Where Verification fits in the wider How Things Work map
Verification connects Standards, Measurement, Comparison, Simulation, Quality, Safety and Feedback.
Its public job is deliberately narrower than Quality or Safety: Verification owns the evidence-backed check that an explicit requirement or claim is satisfied. Whether that requirement was wise, sufficient, ethical or safe remains a separate question.
17. What this article does not claim
- Passing verification does not prove that requirements were complete or correct.
- Passing sampled tests does not prove correctness outside their coverage.
- Reproduction is not automatically validation.
- Independent checking reduces correlated error but does not guarantee truth.
- A model output cannot verify itself merely by being internally consistent.
- Verification does not create medical, legal, safety or regulatory approval.
- A technically verified system may still fail a human receiver.
18. Observable mastery test
You understand verification when you can take an unfamiliar claim or artefact, identify the exact requirement, acceptance criterion, checking method, evidence, uncertainty, coverage envelope and traceability chain; explain the difference between verification and validation; and design an independent check whose failure mode is meaningfully different from the original construction path.
Authoritative source corridor
- NASA Systems Engineering Handbook: Product Realization — current public guidance distinguishing verification and validation and describing product verification.
- NASA Systems Engineering Handbook Appendix — Requirements Verification Matrix and V&V planning structure.
- NASA NPR 7123.1C — verification as proof of compliance with requirements/specifications.
- NASA Software Engineering Handbook: Verification Planning.
- How Simulation Works — verification/validation inside modelling and simulation.
Governing idea: Verification should leave a trail strong enough that confidence survives the departure of the person who originally said, “Trust me, I checked it.”