Every problem-solving and decision-making sequence begins here. Before options can be generated, before a decision can be made, before a response can be executed — the problem has to be correctly identified. Identifies and verifies what and why things have gone wrong is the first behaviour in the Problem Solving and Decision Making competency for exactly this reason. It is the foundation. Get it wrong and everything built on top of it is invalid.
This sounds straightforward. In the simulator, where the failure has been prepared, where the crew are in the right mental frame, where the conditions are controlled — it often is. On the line, where failures arrive unexpectedly, where workload may already be high, where the crew are managing other demands — correct identification is harder than it appears. And the cost of misidentification is not simply an incorrect checklist. It is a crew managing a picture of the situation that does not match the actual one, making decisions from false premises, and potentially not discovering the divergence until it has already had consequences.
What vs Why
The behaviour asks for two things, and the distinction matters. Identifying what has gone wrong is the immediate picture — the failed system, the anomalous indication, the departure from the expected state. Identifying why it has gone wrong is the deeper question — the one that determines the scope of the problem and whether the initial assessment of what has happened is actually correct.
Take an engine failure. What has gone wrong is apparent almost immediately — the indications, the asymmetric thrust, the aircraft's response. Why it has gone wrong is the question that changes everything. Is this a mechanical failure isolated to that engine? A fuel supply issue? A contamination that could affect other systems? Is the cause of this failure something that could be common to the remaining engine?
That last question transforms the diagnosis. An isolated engine failure — a contained mechanical event with no implications for other systems — is one operational picture. A failure whose potential cause is shared is a different picture entirely. The same initial indications. The same immediate checklist items. But a completely different set of implications for what comes next, what the priorities are, and how much time the crew may or may not have to work with.
The engine failure is the cause. The problem is what it changes — and the scope of what it might change is determined by why it failed, not just that it did.
The Real Diagnosis: How It Affects Us
The identification of what and why is not the end of the diagnostic process. It is the input to the real diagnosis — which is not what has failed but what that failure means for the operation from this point forward.
A single engine failure in a modern twin is, in isolation, a manageable event. The performance degradation is known. The configuration changes for the approach are published and practised. The procedural requirements are clear. The range implications at reduced cruising altitude affect the fuel picture in predictable ways. None of these are trivial — they are real changes from the normal operation that require real attention. But they are manageable, briefable, and within the scope of what the crew has prepared for.
The problem is not the engine failure. The problem is the change from the norm — and it is this change, accurately identified and fully understood, that the crew must communicate, plan around, and manage. A crew that identifies the failed engine but does not work through what that failure changes has completed half the diagnosis. The half that determines the response.
The checklist provides the response to an identified failure. It does not provide the diagnosis. A crew that reaches for the checklist before completing the diagnosis has inverted the sequence — they are executing a response before they have confirmed what they are responding to. The checklist assumes the diagnosis is correct. If it is not, the checklist will be completed correctly and the actual problem will remain unaddressed.
This is one of the most important discipline points in non-normal management. The identification and verification step is not a preamble to the checklist. It is the prerequisite for it. Time taken to confirm the diagnosis before beginning the response is not time wasted. It is time invested in ensuring that the response that follows is the right one.
Verification: Confirming What You Think You Know
Identification without verification is a hypothesis. The crew has assessed what has gone wrong and formed a picture of the situation. Verification confirms that the picture is accurate — that the indications are consistent, that the failure is what it appears to be, and that nothing in the available information contradicts the initial assessment.
This matters because initial assessments under pressure are vulnerable to confirmation bias — the tendency to notice information that fits the emerging picture and discount information that complicates it. A crew that has identified an engine failure and moved quickly to the response may not give adequate attention to an indication that suggests the cause is not what they assumed, or that a second system is also affected. The verification step is the deliberate pause that asks: does everything we can observe support this diagnosis, or is there something that does not fit?
Cross-checking is the mechanism. Two crew members, working from the same set of indications, each verifying the diagnosis independently before the response begins. This is where the two-crew advantage is most directly applicable. One crew member's diagnosis is one perspective. Two crew members who have both verified the same diagnosis, and neither of whom has found a contradiction, have a significantly more reliable basis for the response that follows.
The Conditions That Make Diagnosis Possible
Correct identification and verification do not happen in a vacuum. They require specific conditions — conditions that have to be built before the failure occurs, not created in the moment it does.
Spare capacity is the first. A crew that is already saturated when the failure arrives has reduced capacity for the careful, systematic identification that good diagnosis requires. The workload management behaviours that create headspace in normal operations are the same behaviours that preserve diagnostic capacity when it is most needed. A crew that has been disciplined, efficient, and well-organised before the failure is a crew that has capacity available to diagnose it properly. A crew that has been struggling is a crew that will diagnose under conditions that are exactly wrong for accuracy.
Psychological safety is the second. Diagnosis is a crew activity. Both crew members contribute information, cross-check each other's assessments, and challenge assumptions that may not hold. That only works in an environment where speaking up — where questioning the initial diagnosis, where raising a concern that the picture may not be complete — is a valued and normal act rather than a challenge to the captain's authority. The crew that has built that environment before the failure is the crew that can use it when the failure arrives.
SOPs are the third. The baseline that makes deviations detectable. The crew that knows precisely what normal looks like — whose procedures are consistent, whose callouts are reliable, whose expectations are well-calibrated — is the crew that will notice when the situation has departed from it. You can only identify that something has gone wrong if you have a clear reference for what right looks like. That reference is built through disciplined adherence to standards in normal operations.
Diagnosis is not something you do when the failure arrives. It is the product of the discipline, capacity and communication environment that the crew has built across every sector that preceded it.
On the Line
High Performance Pilot structures your development of Identifies and Verifies What and Why Things Have Gone Wrong across three levels — Foundation, Proficient, and Mastery. Each session takes minutes. The development happens on every flight. Free to start.
Start Free — highperformancepilot.com