Risk, Assumption, Issue, and Validation Gap: Getting the Definitions Right
These four terms are used interchangeably in most engineering programmes. They are not the same. Getting the definitions right is the first step to managing them well.
In most engineering programmes, the words risk, assumption, issue, and validation gap are treated as rough synonyms. They appear in the same tracker. They are reviewed in the same meeting. They are closed by the same process.
This is not wrong in intent. It is wrong in effect. Each term describes a different kind of claim about the design, and conflating them makes it harder to manage any of them.
Four definitions
Risk is a future condition that may or may not occur. It has a likelihood and a consequence. The likelihood is uncertain. The consequence, if it occurs, is specific. Risks are managed: mitigated, accepted, or transferred. They are closed when the condition is either eliminated or accepted with documented rationale.
Assumption is a claim held to be true for the purpose of making design progress. It is not uncertain in the way a risk is uncertain; it is treated as settled, even though it has not been verified. Assumptions are not inherently bad. Every design is built on them. The failure mode is when assumptions are held implicitly and no one tracks what would happen if one turned out to be false.
Issue is a known condition that is currently adversely affecting the design or programme. Unlike a risk, it has already occurred. It does not need a likelihood assessment; it needs a resolution. Issues are closed when the condition is resolved, not when someone writes “acknowledged.”
Validation gap is the absence of evidence that a requirement is met. It is not a risk, because no failure has been predicted. It is not an assumption, because no claim has been made. It is simply a hole in the evidence base: something that must be true for the design to work, for which no test or analysis has yet produced supporting data.
Why the distinctions matter
The practical consequence of conflating these terms is that each gets managed incorrectly.
Risks that are actually assumptions get assigned likelihoods that someone invented, and mitigation plans that amount to “we will check this later.” The assumption was never surfaced for what it is: a load-bearing claim about the design that needs a verification activity, not a risk score.
Assumptions that are actually validation gaps get treated as design decisions, closed out in a model or analysis that assumes the same thing the assumption states. The loop is circular and invisible.
Issues that are tracked as risks never get the urgency that a current adverse condition requires. “Likelihood: medium” is a comfortable home for something that is actively happening.
A simple test
When an item appears in your tracker, ask:
- Has this adverse condition already occurred? If yes, it is an issue.
- Is this a claim we are treating as true without evidence? If yes, it is an assumption.
- Is there a requirement this design must meet for which we have no supporting evidence? If yes, it is a validation gap.
- Is this something that might happen, with specific consequence if it does? If yes, it is a risk.
These questions take twenty seconds per item. They sharpen every subsequent conversation about it.