The Loop That
Has to Close

There is a word in this behaviour that carries more weight than it first appears: expected. Not just verifies tasks are complete. Verifies tasks are completed to expected outcome. That qualifier changes everything. It is the difference between confirming that an action was taken and confirming that the action produced the result it was supposed to produce.

Those are not the same thing. An action can be taken correctly and still produce an unexpected result — a mode that does not capture, an automation that transitions to a different state than intended, a system that responds to an input in a way the crew did not anticipate. The task is not complete until the outcome has been observed and confirmed against what was expected. Anything short of that is an open loop.

The Prerequisite: Knowing What Right Looks Like

Before verification is possible, the expected outcome has to be known. This is the knowledge dimension of the behaviour — and it is the foundation on which everything else rests. To verify that the autopilot has captured the selected altitude, you have to know what mode annunciation and aircraft response should accompany that capture. To verify that a system selection has taken effect, you have to know what the system should do in response. To verify that a checklist action is complete to expected outcome, you have to know what complete looks like.

This is where Application of Knowledge feeds directly into Workload Management. The crew member whose system knowledge is precise has a precise expected outcome to verify against. The one whose knowledge is approximate will have an approximate ability to detect when the outcome has not been achieved — and will therefore close the loop on tasks that are not actually complete.

The automation environment makes this particularly significant. Modern flight deck systems respond to inputs in ways that require understanding to interpret. A mode selection is not complete at the button press. It is complete when the mode has annunciated, the flight director has responded, and the aircraft is tracking the intended path. That three-step sequence — action, mode response, monitoring — is the closed loop. Stopping at step one is not verification. It is the appearance of it.

Where the Loop Gets Opened

Most incomplete verifications are not the result of carelessness. They are the result of distraction — the interruption that arrives between the action and the confirmation, redirecting attention before the loop is closed. The SELCAL call that arrives as the mode is transitioning. The cabin call that comes in during the checklist. The ATC instruction that demands immediate processing while a system is still responding to an earlier input.

In each case the action was taken. In each case the attention that should have confirmed the outcome was drawn away before it could do so. And in each case the task carries the appearance of completion — it was initiated, the crew member has moved on — while the loop is actually still open.

This is the workload dimension. High workload does not just add tasks to the queue. It creates conditions in which the verification step — which requires focused attention directed at a specific expected outcome — is the first thing to be displaced. The task gets initiated. The confirmation gets deferred. The deferral gets forgotten. And the crew proceeds on the assumption that the task is complete, when the only thing that is certain is that it was started.

Verification Is Part of the Flow

The most effective form of this behaviour is not verification added onto the end of tasks as a discrete check. It is verification built into the flow of the task itself — the callout that confirms the mode, the cross-check that confirms the response, the challenge-and-response that closes the loop as part of the procedure rather than after it.

Standard operating procedures are designed with this in mind. The challenge-and-response checklist does not just ensure the action is taken — it ensures the action is confirmed. The callout at the point of a mode selection does not just communicate the selection — it creates the shared expectation against which both crew members are now monitoring. The cross-check is not a bureaucratic step. It is the mechanism that closes the loop for both pilots simultaneously.

When verification is treated as part of the flow — not an addition to it — it becomes automatic. The confirmation happens because the procedure requires it, not because the crew member has to remember to do it under conditions where remembering is exactly what high workload makes difficult. The procedure carries the discipline when the crew member cannot.

Normal Operations Build the Habit

This is where the argument about non-normal situations lands with full force. Verification to expected outcome under the conditions of a demanding non-normal — high workload, time pressure, multiple competing demands, reduced spare capacity — requires a level of automatic, disciplined behaviour that cannot be summoned on demand. It has to be built across the thousands of normal operations that precede it.

The crew member who verifies consistently in normal operations — who always closes the loop, who never assumes completion from initiation — has built the habit into their operating style. Under pressure, that habit runs. The loop closes because it always closes. The confirmation happens because it always happens. The discipline that was practised in normal operations is the discipline that is available in the non-normal.

The crew member who is inconsistent in normal operations — who sometimes closes the loop and sometimes assumes completion — has no such automaticity to fall back on. Under pressure, the inconsistency that was manageable in routine conditions becomes the gap through which errors pass undetected. The non-normal does not create the discipline that was absent in the normal. It exposes its absence.