The SMART System, the Congressional Pause Request, and the Safety Testing Questions the FAA Has to Answer Before Automation Runs the Nation's Airspace

A formal letter from members of Congress, as reported by AVweb, has asked the Federal Aviation Administration to pause the rollout of a tool called SMART - an automated decision support system being deployed inside the nation’s air traffic control infrastructure. The request does not call for cancellation. It calls for demonstration: show that the system has been properly tested, that controllers have been properly trained, and that a real oversight mechanism exists. Those are three distinct concerns, and each one carries real weight.

What Is the SMART System and Why Is Congress Asking Questions?

The FAA has been deploying SMART into operational air traffic control facilities. The full scope of that deployment - which facilities, how widely, and for how long - is not entirely transparent from public documents. What is clear is that the congressional letter raises foundational questions about whether the validation work that should precede live operational use has actually been completed to a verifiable standard.

This is not a fringe concern. It is the same question applied to every safety-critical system in aviation: was the testing done, and can anyone outside the agency verify it?

The Safety Testing Problem

When new avionics enter a cockpit, a defined certification path governs the process. Failure modes are mapped in controlled environments. The system must perform under nominal conditions and under edge cases - scenarios the designers didn’t anticipate but that real flight operations eventually produce. That process is slow by design. The cost of discovering a problem in testing is documentation. The cost of discovering it in service can be lives.

SMART operates in the ATC environment rather than the cockpit, but the principle doesn’t change. Safety-critical tools that inform real-time human decisions in a complex, dynamic environment require rigorous validation before going live. The congressional letter raises the concern that this validation may not have been completed to a standard that allows outside verification.

Every complex system eventually encounters conditions it wasn’t designed for. The question isn’t whether SMART will occasionally produce a bad recommendation - it will. The question is whether anyone has systematically established the conditions under which it fails, the frequency of those failures, and whether human controllers can reliably catch those errors before they compound.

Automation Bias: Why Controller Training Is a Human Factors Issue

Air traffic control is among the most cognitively demanding professions in existence. Controllers manage three-dimensional mental models of airspace in real time - sequencing arrivals, coordinating departures, issuing traffic advisories, managing weather deviations - all simultaneously, using voice communications as their primary interface.

Introducing a new tool into that environment isn’t a mechanical training problem. It requires building the right mental model of what the tool can do, what it cannot do, and when not to trust it.

This is where automation bias becomes the central concern. Automation bias is a well-documented phenomenon in aviation human factors research: the tendency for skilled operators to defer to automated recommendations even when their own judgment would flag the output as suspect. The more reliable the system has historically been, the stronger that bias becomes. It isn’t a failure of intelligence. It is a predictable cognitive response to high workload combined with high system reliability - the operator is busy, the system is usually right, and verifying the output requires cognitive resources the operator may not have available.

Commercial aviation learned this the hard way. The glass cockpit transition of the 1980s and 1990s produced a generation of accidents centered on automation and human-automation interaction failures. Flight crews deferred to flight management system outputs without adequate cross-checking. Aircraft flew precisely described trajectories into terrain while trained pilots failed to intervene because the automation appeared to be handling the situation. The industry responded with training overhauls, interface redesigns, and a fundamental cultural shift in how pilots are taught to relate to automated systems.

The ATC community now faces a version of that same challenge. A controller trained to use SMART but not trained to recognize its limitations is, in a meaningful sense, more vulnerable than a controller who never had the tool at all. They have a false safety net. The congressional letter is asking whether the training program adequately addresses this. That is exactly the right question.

The Oversight Gap: Who Catches Problems After Deployment?

A system isn’t safe because it passed initial validation. It remains safe because there is an ongoing mechanism to detect when performance drifts from expected parameters.

Aviation has built remarkable infrastructure for this. The Aviation Safety Reporting System (ASRS), administered by NASA, allows anyone in the aviation ecosystem to file anomaly reports without fear of certificate action in most circumstances. Aviation Safety Action Programs (ASAPs) create structured feedback loops within airlines. Flight Operational Quality Assurance (FOQA) programs monitor parameters across every flight. These systems were designed before the operations they monitor, not retrofitted afterward.

The equivalent for an automated ATC tool needs to be defined before deployment. If a controller notices that SMART is consistently mischaracterizing traffic in a particular configuration, who do they tell? Where does that report go? What threshold triggers a formal review? What is the process for removing the system from service if it is identified as a contributing factor in a loss of separation or a runway incursion?

These are operational requirements, not hypothetical questions. The congressional letter suggests those requirements have not been fully established.

Why FAA Staffing Pressure Makes This More Complicated

The FAA has faced a chronic controller staffing problem that predates the pandemic and was compounded by it. Retirements have outpaced hiring at some facilities. Controllers in many locations are working mandatory overtime at rates that raise their own safety questions. Workload is up. Staffing is down.

Into that environment, technology that reduces cognitive load is genuinely appealing. If SMART can sequence traffic more efficiently, identify conflicts earlier, or reduce mental overhead in a heavy sector, those are real safety benefits. No one is arguing that automated tools have no role in the future ATC system.

The argument is about sequence and rigor. Deploy the tool after the validation, not alongside it. Build training around what the tool actually does in real-world conditions. Stand up the oversight mechanism before the first live operation. When an organization is under resource pressure, the temptation is to use technology to bridge the gap before that technology is fully understood. Sometimes that works. Sometimes it introduces new failure modes that compound the original problem. Aviation has historically held a higher standard on this question because the consequences of getting it wrong are what they are.

What Pilots Can Do Right Now

Pilots have no visibility into what SMART is recommending on the other end of their radio frequency. What every pilot does have is their own situational awareness - and the right to use it.

Read back every clearance. If a routing feels unusual for the conditions, if a traffic call doesn’t add up geometrically based on your position and heading, if an instruction would put you somewhere inconsistent with your picture of the airspace, say something. This is not second-guessing the controller. This is the system working exactly as designed. Controllers are trained to expect complete readbacks and to catch deviations in them.

That dynamic matters especially if an automated tool is occasionally producing questionable outputs. A pilot who notices a clearance that doesn’t make sense and speaks up gives the controller an opportunity to catch an error before it propagates. That feedback loop functions independently of whatever tools are on the scope.

What to Watch For

The FAA’s response to this congressional letter will be instructive. If the agency returns with detailed validation data, documented training curricula, and a defined oversight framework, the concerns raised are addressable. If the response is vague or delayed, the pause request will gain traction - and appropriately so.

The airspace of 2035 will look nothing like the airspace of 2005. Advanced air mobility platforms, scaling uncrewed operations, new-entrant aircraft at every altitude - the complexity of what the ATC system will need to manage requires tools that don’t yet fully exist. Automated systems will be central to that future. But the trust that allows those tools to operate in safety-critical roles has to be earned, system by system, through rigorous validation, honest training, and real oversight.

Aviation got where it is by treating safety data as a shared resource. Incident reports, accident investigations, certification records, maintenance history - all of it feeds a system that learns from near-misses and makes corrections before mistakes repeat. That model must apply to automated tools being deployed in safety-critical aviation functions. The congressional letter is asking the FAA to demonstrate that it does.

Key Takeaways

Members of Congress have formally requested the FAA pause the SMART system rollout until safety testing, training, and oversight can be independently verified.
The core concern is not the technology itself - it’s whether the validation and human factors work that should precede live operational use has been completed.
Automation bias is a documented human factors risk: controllers trained to rely on SMART without training on its failure modes may be more vulnerable than controllers without the tool.
An oversight mechanism for catching post-deployment problems - equivalent to ASRS or FOQA - must be defined before deployment, not after.
For pilots, the practical response is unchanged: complete readbacks, active situational awareness, and willingness to question clearances that don’t fit your picture are safety layers that function regardless of what tools the controller has available.