15  Principle Five — Validation Is a Deliverable

Ask a vendor whether their clinical tool is validated and you will hear about the tool’s validation — test scripts executed once at installation, a binder on a shelf, a certificate with a signature. This model made sense when software was bought as an appliance. It fits a pipeline about as well as a horseshoe fits a car.

The principle: validation belongs to the product, ships with the product, and is exercised by the product’s own machinery. Not a one-time ceremony performed on a version; a living artifact that every release carries and every execution strengthens.

15.1 What ships, then

A validation-ready product carries four kinds of evidence, in order of increasing persuasion:

• A validation plan that states scope honestly: what the system claims to do, what it explicitly does not, which standards frame the work, and what risks were assessed as irrelevant and why.
• A traceability matrix connecting every claimed capability to the tests that demonstrate it. When a requirement has no test, the matrix must say so in red rather than leaving the row ambiguously green. The most valuable cell in any such matrix is an honest “not yet verified.”
• Operational qualification executed against reality — the actual engines, the actual render path, the actual comparisons — not a stubbed demo. A qualification that passes only in a sandbox with mocked dependencies certifies the sandbox.
• Reproducible runs: recorded executions with manifests, so a third party can re-run the qualification and compare. Validation you cannot reproduce is an anecdote with a signature.

15.2 Risk-based, honestly

Full re-validation of everything at every release is how validation becomes the thing teams route around. The workable alternative is risk-based scope, applied without vanity: components whose failure corrupts delivered numbers get the heaviest regime; components that merely render or display get lighter ones; and the risk assessment itself — likelihood, impact, mitigation — is a reviewed document, because it is where all the judgment lives.

A subtle but crucial practice: maintain a deviation log in the open. When qualification uncovers a real defect — and it will — the record of the finding, the fix, and the re-run is more persuasive to any serious auditor than a spotless history, because a spotless history is indistinguishable from an unexamined one.

15.3 The economics

Here is the commercial punchline. In most organizations, validation is a cost center staffed by people who wish they were doing anything else. Delivered with a product, it flips: the validation package becomes the thing a buyer cannot cheaply produce for themselves. A CRO can download a table engine in an afternoon; it cannot download a qualification suite traceably executed against its claimed capabilities, with reproducible runs and a maintained traceability matrix. That package — boring, meticulous, included — is a moat made of paperwork that nobody has to pretend to enjoy writing, because the system writes most of it as a side effect of its own operation.

The test. Ask any vendor: “Hand me the validation package for the exact version I would run today, and let me re-execute one qualification run myself.” If the package is out of date, out of scope, out of stock — or if re-execution requires the vendor’s laptop — the validation belongs to their sales process, not to the product.