Verification, Validation, and Certification

Verification determines whether an output satisfies its specified inputs and requirements. It may use review, analysis, inspection, demonstration, or test. The selected method must be appropriate to the claim: a visual inspection cannot verify timing behaviour, while a functional test may not establish an internal design constraint.

Verification evidence should identify:

• the requirement or property under examination;
• the system configuration and test environment;
• the procedure, inputs, and acceptance criteria;
• the observed result and any deviation;
• the identity and version of the resulting record.

Validation concerns intended use. A system may conform perfectly to an incomplete or unsuitable specification and still fail operationally. Validation therefore requires representative scenarios, users, interfaces, environmental conditions, and assumptions.

In practice, validation often exposes gaps that individual component tests cannot reveal: ambiguous operational rules, unexpected interactions, inadequate degraded modes, or incorrect assumptions about human behaviour.

Independent assessment evaluates the adequacy of processes, arguments, and evidence without taking ownership of the design. Certification or authorisation then uses the applicable institutional and regulatory framework to determine whether the required demonstration has been made.

Independence does not remove the need for technical dialogue. It changes the responsibility and evidential weight of the conclusion.

Evidence is valid only for the configuration it actually examines. Software version, hardware variant, parameter set, test equipment, requirements baseline, and known anomalies may all affect applicability.

This is why configuration management cannot be reduced to file naming. A perfectly archived report attached to the wrong baseline is still the wrong evidence.

• requirements that cannot be tested objectively;
• traceability links created without semantic review;
• test results detached from their configuration;
• anomalies closed administratively without technical justification;
• copied arguments that no longer match the current design;
• certification evidence assembled only at the end of the project.

The durable remedy is to build the evidence chain throughout development and to treat inconsistencies as technical defects rather than formatting problems.