Validation is not review, and your review is not validation

Two words that keep being swapped

Review looks at a document. Validation looks at whether the specified system is the right system for the stakeholders who will live with it. The CPRE Foundation Level syllabus (English v3.2.0, 26 February 2024) keeps verification and validation apart; the glossary (v2.2.0) does the same. A review can be a verification activity. It is not, by itself, validation.

Teams swap the words because both involve people sitting around a table. The table is not the method. This essay keeps a table of contents and a reading column on purpose: the argument is long, and the headings are the map.

What a review can tell you

A requirements review can find:

• contradictions between statements
• missing structure (a quality need without a scale, a constraint without a source)
• ambiguous terms that the glossary would have caught
• traces that do not reach the origin of a statement

That is valuable. It is still a check of the specification artefact. You can have a clean review record and still be specifying the wrong problem.

The record

Keep the review findings on the artefact: contradictions, missing scales, undefined terms, broken traces. That list is the review record. Do not later relabel it as validation evidence.

What the record cannot carry

A signed PDF cannot testify that a clerk can complete the search task. It cannot testify that the neighbour system still exists in the form the interface list assumes. It cannot testify that the quality target is the one operations will actually defend at go-live. Those are empirical claims. Reviews do not gather them.

What validation has to ask

Validation asks whether the specified system would be acceptable to the people who have a stake in it. That question cannot be answered only by reading the document more carefully. It needs contact with the world the document claims to describe: tasks, current workarounds, examples, and the conditions under which someone would reject the result.

If the only evidence you have is "the steering group signed the PDF", you have a review outcome. You do not yet have validation evidence.

The Foundation Level does not require a particular workshop recipe. It does require that you can tell the two questions apart, and that you do not treat a review attendance list as proof that the right problem is being solved.

A meeting that felt like both

The transcript is deliberately ordinary. Nobody is a villain. The failure is the relabel. Once "reviewed" becomes "validated" in the minutes, the open empirical work disappears from the plan.

Evidence, not atmosphere

flowchart LR
  A[Specification artefact] --> B[Review]
  B --> C[Verification findings]
  D[Stakeholders in their work] --> E[Validation]
  E --> F[Accept or reject the specified system]
  C -.->|does not replace| F

You can do more, and sometimes you must: prototypes, scenarios walked in the real workplace, explicit rejection criteria. The Foundation Level does not hand you a numbered catalogue of techniques as if they were the exam. It does insist that validation is a different question from "did we inspect the document?"

Negotiation sits beside both

Requirements negotiation is its own activity: conflicts between stakeholders, conflicts between quality targets, conflicts between a wish and a constraint. A review can surface those conflicts on the page. Validation can surface them in the world. Neither activity is the negotiation. If the minutes say "agreed" because the loudest person stopped talking, you have neither a review outcome worth keeping nor validation evidence.

How to keep the words honest in a programme

Give the two activities different artefacts. The review record lists findings on the specification. The validation record lists probes into the work: who was observed, what task, what would count as rejection. If a programme will only fund one of them, say so in the plan. Do not fund a review and then report it as validation to make the milestone turn green.

That honesty is harder than a glossary. It is also the only way a later incident review will not discover that nobody ever asked whether the specified system was the right one.

A note on verification

Verification is the broader twin: checking a work product against criteria. Reviews, traces, inspections, and tests of the specification against a template are verification. Validation is not "verification but friendlier". It is a different claim: the right problem, the right stakeholders, the specified system as a fit. Keep the words. They are doing work.

What to write down so the next person can tell them apart

If you only change the vocabulary in conversation, the collapse will return the first time someone copies a slide. Write two headings in the plan, two evidence lists, and two close criteria. Review evidence is comments, traces, inspections, template checks. Validation evidence is observations, scenario walks, stakeholder rejection criteria, probes that could have failed. If a line of evidence could sit under either heading, it is not yet classified. Classify it or drop it.

The Foundation Level does not require a particular template for those lists. It requires that the activities are not the same activity. A programme that uses one Word file for both can still be honest: two chapters, two owners, two dates. A programme that uses a sophisticated ALM tool can still be dishonest: one workflow named "Validate requirements" that is a review. Tools do not save the distinction. Named evidence does.

When a late defect is labelled "requirements issue", ask which evidence was missing. If the document was inspected and the probe was never run, say so. That is not blame. It is how you stop paying for the same mix-up on the next release. The long table of contents on this page exists so you can point at a heading instead of improvising the speech. Use the heading. Then write the two lists.

What a programme looks like when the words have already collapsed

You can usually see the collapse in the milestone names. "Requirements validated" sits on a Gantt chart with a single date and a single exit criterion: a signed document. The people who will live with the system are listed as optional attendees. The quality requirement that depends on a clerk's actual task has never been watched in the workplace. The constraint that depends on a neighbour interface has been checked against a wiki page last edited two years ago. None of this is exotic. It is the default.

When an incident later shows that the specified search does not match the job, the review record is produced as if it were a defence. It is not a defence. It is evidence that a document was inspected. The missing work has a name. Calling it "more review" will produce more comments in the margins and the same search.

A healthier programme still reviews. It also funds at least one probe that could falsify the specified system: observe the task, walk the scenario in the real tools, ask a stakeholder what would make them reject the result. Write that probe down as validation evidence, with a date and a name. If the probe is refused, write the refusal down too. An explicit gap is a management object. A relabelled review is a fiction.

There is a cultural difficulty. Review feels like governance. Validation feels like delay. Governance prefers a signature because a signature is easy to file. The Foundation Level does not exist to make governance feel efficient. It exists to keep two questions from being filed as one. You can satisfy a governance template and still keep the words honest: list the review outcome and the validation outcome on separate lines. If one line is empty, the milestone is not "validated". It is "reviewed, validation outstanding".

Analysts sometimes try to smuggle validation into a review by inviting "the business" and asking "any objections?" Silence is not acceptance of the specified system. Silence is often politeness, or the absence of the people who actually do the work. If the clerk is not in the room, you did not even attempt the cheap probe. If the clerk is in the room but has never seen the task performed against the proposed quality target, you still do not have the evidence. You have a conversation.

None of this requires a laboratory. It requires that the plan names both activities, that the artefacts stay distinct, and that nobody is rewarded for turning a signature into a synonym. The table of contents on this page is long because the mix-up is sticky. If you only take one heading into the next review, take "Evidence, not atmosphere." Then ask what would count as rejection. If nobody can answer, you are not validating yet. You are still reviewing the comfort of the room.

A last operational habit: never let a single checkbox on a quality gate mean both "the document was inspected" and "the specified system is acceptable to the people who will live with it." Split the checkbox. Review can close when the inspection record is complete. Validation can close only when the named probe has been run or explicitly waived. If your tool cannot split the checkbox, the tool is not the process. Write two lines in the plan and keep them. The Foundation Level split is the reason those two lines exist. Using one line because the tool is easier is how the words collapse again.