Department.Technology

Category: FAA

Federal Aviation Administration

  • Build It With the Controllers: The Danger of Rolling Out SMART Without NATCA

    By the Founders, Department of Technology | San Diego, California | November 15, 2026

    The FAA is using MI (Machine Intelligence, aka AI or Artificial Intelligence) to help manage the nation’s airspace. The tool, called SMART, began limited operation around Washington, D.C. on September 21 and was expanded to all 22 air route traffic control centers on November 10, three days before the November 13 ground stop. The union that represents air traffic controllers says it had no part in designing, testing, or implementing it.

    We are not claiming that SMART is unsafe, or that it caused the ground stop. Officials say it did not, and the cause has not been confirmed. Our claim is narrower: when a critical system is rolled out without the people who use it every day, the risks go up, and the cost of avoiding them is small. This is the third post in our series. Our first post asked what accountable technology leadership would have changed, and our second asked what should be settled before $50 billion is spent.

    What we know so far

    Here is what has been reported. Most of the reporting on the union’s role dates from September.

    • The rollout. The FAA began limited use of SMART in the Washington area in September. It told FLYING that SMART was active in all 22 centers as of November 10, and AeroTime reported that the expansion came after lawmakers had sought a pause in the Washington-area rollout.
    • The union’s position. In September, the National Air Traffic Controllers Association (NATCA) said it had not been involved in the design, testing, or implementation of SMART and could not speak to its effect on the workforce, as NPR reported. FLYING reported that the union stressed that new technology should complement controllers’ judgment, not replace it.
    • A lawmaker’s account. Rep. Don Beyer called on the FAA to suspend SMART at Washington-area airports until controller feedback and independent stress testing showed it was safe. He said he had been told that controllers were not consulted on its design and development, were not trained on it before it went live, and had been told it can adjust schedules and potentially even routes, according to Common Dreams. That is his account, and we have not seen the FAA respond to it directly.
    • The FAA’s description. The FAA says SMART cannot replace controllers or take over an aircraft, and that every recommendation is reviewed by FAA staff, with local leadership free to accept or pass, per MeriTalk. The agency credits the Washington rollout with saving an average of 10 minutes per rerouted flight, according to AeroTime.
    • The ground stop. Officials said Friday’s outage was not related to SMART, as the Taos News reported, and we have no reason to doubt that.

    What we do not know

    Several basic questions are still open.

    • Whether the FAA consulted controllers or facility leaders in other ways. To our knowledge, the agency has not described what consultation took place.
    • Whether NATCA has been brought in since September. We found no union statement on the November expansion.
    • What testing was finished before the expansion, and what criteria had to be met first. Airways noted that the FAA’s November statement does not explain how its savings were calculated, give a comparison baseline, or report how often facilities accepted recommendations.
    • The cause of the ground stop, which has not been confirmed.

    Five dangers of skipping the people who use the system

    Everything in this section is our analysis, not reporting.

    1. A human review is only as good as the reviewer’s understanding

    The FAA stresses that staff review every SMART recommendation. That safeguard depends on people who understand what the tool is doing, trust it enough to use it, and doubt it enough to challenge it. People who were not involved in building or testing a tool, and who may not have been trained on it, are more likely to accept its output without question or to ignore it altogether. Either outcome defeats the purpose of keeping a human in the loop.

    2. Designers miss what operators know

    Controllers know how traffic really moves at their facilities, where the workarounds are, and what a recommendation looks like in the middle of a busy shift. That knowledge rarely makes it into a specification. Bringing it in during design is far cheaper than discovering its absence after go-live.

    3. Mixed messages about what the tool does

    The FAA describes SMART as advisory. According to Beyer, controllers were told it can adjust schedules and possibly routes. We cannot say which description is right, and the gap itself is the danger. In a safety-critical workplace, people need to know exactly what a tool can and cannot do, and who has the final say. A joint design and review process is how those answers get written down and shared.

    4. Speed without a shared record of what was learned

    About seven weeks passed between the first Washington-area use on September 21 and the nationwide expansion on November 10. A staged rollout is a sound idea, but a stage only teaches something if the results are examined, ideally by people with independent standing. As noted above, we have not seen public figures on how often facilities accepted SMART’s recommendations. Union representatives who help review each stage, against criteria agreed in advance, would give the process a credibility that an internal sign-off alone cannot.

    5. Goodwill is scarce, and so is public trust

    The FAA is still thousands of certified controllers short of full staffing, and many work mandatory overtime and grueling schedules, according to NPR. Asking a stretched workforce to adopt a major new tool it did not help shape spends goodwill the agency can ill afford. And when something goes wrong, as it did on November 13, a thin public record of how the tool was vetted leaves room for speculation. Headlines linked the ground stop to the SMART expansion the same day, even though officials said the two were unrelated. A visible partnership with the controllers’ union would have been part of the answer to that question.

    What investing the time would look like

    None of this requires slowing the work to a crawl. Based on the problems above, these are the steps we would suggest. They are our proposals, not the FAA’s plan.

    • An early invitation. Bring the union into design review before a system is built, and into testing before it goes live.
    • Training before go-live. Train every controller and traffic manager who will see the tool’s output, and give them a clear written statement of what it can and cannot do.
    • Joint review at each stage. Agree in advance on the criteria for moving from one stage to the next, and have the union help review the results.
    • A public report. Publish what was tested, what was found, and what changed, including how often recommendations were accepted or passed.

    Where reasonable people disagree

    Supporters of the current approach point to the staged rollout, the FAA’s reported savings, and the fact that SMART is advisory and reviewed by FAA staff. Airlines for America praised the push to modernize, according to NPR. Skeptics, including Beyer, argue that a tool with safety implications should be vetted with controller feedback and independent testing first. We think both sides have a point. Inviting the union in is not the same as giving it a veto, and it does not have to be slow. It is a way of finding problems early, while they are cheap to fix.

    Where a Department of Technology fits, and where it does not

    A Department of Technology would not design SMART, run air traffic control, or negotiate with NATCA. As described in our federal framework, it would audit major technology initiatives, require impact assessments, and report to Congress and the public. We would add one requirement that goes beyond the written framework: for any major system that changes how safety-critical workers do their jobs, the sponsoring agency must document how those workers and their representatives were consulted before rollout. That ties together two arguments we have already made: that changes should be tested before they go live, as in our first post, and that leaders should understand how systems work in practice, as in Back to Basics.

    Questions for officials and candidates

    1. Was NATCA invited to help design, test, or review SMART before the September launch, and before the November expansion? If not, why not?
    2. What testing and review had to be completed before SMART was expanded to all 22 centers, and who signed off?
    3. How were controllers trained on SMART, and what were they told it can and cannot do?
    4. How often do facilities accept or pass on SMART’s recommendations, and will that data be made public?
    5. Will you commit to involving the workforce and its representatives in design and testing for the next major system?

    The bottom line

    A tool that helps manage the nation’s airspace should be built with the people who keep planes apart, not delivered to them. The time and goodwill it takes to invite the union in are small compared with the cost of losing the trust of the workforce, or the public, in a system everyone depends on. Whether or not SMART had anything to do with November 13, the lesson is the same one running through this series: name who is responsible, test before you go live, and show your work.

    Read the rest of this series: The November 13 Ground Stop: What a Department of Technology Would Have Done Differently and Fiber First? The Questions to Ask Before $50 Billion for Air Traffic Control For the basics of our proposal, read What Is a Department of Technology? We will update this post as more is reported, including any response from the FAA or NATCA.

  • Fiber First? The Questions to Ask Before $50 Billion for Air Traffic Control

    By the Founders, Department of Technology | San Diego, California | November 14, 2026

    On Friday, November 13, the FAA grounded flights nationwide for more than four hours. In our first post, The November 13 Ground Stop: What a Department of Technology Would Have Done Differently, we argued that accountable technology leadership could make a failure like this less likely. Since then, the conversation has turned to money, and a natural question has come up: should we lay the fiber and the wiring first?

    Our short answer is yes, the network has to be the top priority. But “fiber first, everything else later” is not how a system that can never be switched off actually gets rebuilt. What matters even more than the order of the work is whether someone is accountable for the result. Below, we summarize what has been reported since the outage, explain why the network is the base layer and why the work cannot be strictly sequential, and set out four questions to settle before a check is written.

    What has been reported since our first post

    The cause of the outage has still not been confirmed, and the story is still developing. Here is what has been reported so far.

    • The funding request. Transportation Secretary Sean Duffy asked Congress for $50 billion in emergency funding to overhaul air traffic control, saying, “This is an emergency,” according to Bloomberg. He had asked for about $30 billion earlier in the day. The Standard reported that the earlier $30.1 billion request included $10.1 billion for air traffic control modernization, $2 billion for control towers, and $18 billion for airport projects.
    • The legislation. Duffy is urging passage of the Modern Skies Act, which would set aside $10 billion to finish upgrades to the digital architecture behind air traffic control, including telecommunications networks, according to ANI.
    • The money already approved. Congress approved $12.5 billion over five years in July 2025 for air traffic control upgrades and controller hiring, per The Jerusalem Post. Duffy says more is needed to finish the job. The Standard also reported that the administration wants action in the final weeks of the year, before the new Congress takes office in January.
    • Congressional oversight. Sen. Maria Cantwell said the Commerce Committee would review the outage, including the technology behind primary and backup communications frequencies, according to Implicator.
    • Competing explanations. Duffy blamed old, overloaded switches and routers, and our first post noted that Homeland Security Secretary Markwayne Mullin pointed instead to FAA updates added to the old system. Implicator reported that multiple sources told CBS News an update to the private network connecting the air traffic control system caused the failure. Officials have not reconciled these accounts.

    Why the network is the base layer

    It helps to think of air traffic control as three layers. At the bottom is the network: the copper lines, fiber, switches and routers that carry voice, radar and data between facilities. In the middle are the systems that use that data to track aircraft and keep them apart. At the top are the planning tools that decide when and where flights should go.

    That top layer now includes a new FAA scheduling and flow-management system called SMART, short for Strategic Management of Airspace, Routes and Trajectories. It is MI-powered, and MI (Machine Intelligence, aka AI or Artificial Intelligence) is the term we use throughout this site. According to the Department of Transportation fact sheet, SMART analyzes airline schedules, weather and airport capacity to predict congestion before it builds. It began limited operation around Washington, D.C. in September, and NPR reported that FAA and DOT leaders emphasize it is not a replacement for human air traffic controllers.

    The FAA expanded SMART to all 22 air route traffic control centers on November 10, three days before the ground stop, according to FLYING, which is why the question has come up. Officials said Friday’s outage was not related to SMART, as the Taos News reported, and we have no reason to doubt that. The distinction matters for another reason, too. A planning tool cannot keep a network up. If the layer underneath fails, the smartest scheduling in the world does not help, because controllers cannot reach one another and planes stay on the ground. That is why we believe the backbone deserves first claim on attention and money. Our third post asks a related question: whether the controllers who use SMART were brought in before it went live.

    Why “fiber first” cannot be strictly sequential

    In our view, there are four practical reasons the work cannot simply be done in a neat order.

    • The system cannot be turned off. Air traffic control runs around the clock, so new connections have to be built alongside the old ones and cut over carefully. The FAA has said it expects to replace the remaining copper telecommunications wiring by September 2027, according to Travel Noire.
    • The projects are different workstreams. Scheduling software, towers, radar and telecommunications involve different vendors, contracts and timelines. Pausing one does not automatically speed up another.
    • How we change things matters. If the outage did follow a network update, as the CBS sources suggest, the lesson is that rollout practice matters as much as the hardware. This is the change-management point from our first post. New gear installed poorly can fail just as badly as old gear.
    • The scale is large. A Government Accountability Office review found that 51 of the FAA’s 138 air traffic control systems are unsustainable, and the FAA told GAO not to expect many modernization projects to be completed for at least a decade.

    Where reasonable people disagree

    Supporters of a large, up-front commitment argue that years of stop-and-start funding and shifting priorities are a core reason the system aged the way it did. Duffy has said the money is needed up front, as reported by KMPH. Skeptics point to the size of the request, the long history of delayed modernization projects, and the question of how the money will actually be tracked. Both concerns are fair, and they point to the same need: clear milestones and public reporting, whatever the final amount. That need is the thread running through the four questions below.

    Four accountability questions before a check is written

    These four questions apply the ideas from our first post to the funding request.

    1. Who owns the backbone? One accountable leader, with a name, should be responsible for the reliability of the communications network that air traffic control depends on.
    2. What are the milestones? A public schedule should say which facilities are being upgraded, by when, and how independent auditors will verify it. This is the kind of work our proposed Technology Oversight Committee is designed to do under our federal framework.
    3. How are changes tested and reversed? Critical systems should get staged rollouts and rehearsed rollback plans. That is our suggestion and goes beyond the written framework.
    4. What happens after an outage? Every major failure should produce a public post-incident report that explains what failed, why, and what will change.

    Where a Department of Technology fits, and where it does not

    A Department of Technology would not run air traffic control, write the funding bill, or replace equipment overnight. It would be the accountable layer around the work: auditing legacy systems across agencies, putting hands-on network expertise at the top, coordinating across agencies, and reporting to the public. We cannot say it would have prevented this outage, since the cause is not yet known. Our narrower claim, as we argued in Back to Basics, is that leaders who understand networks, and who answer to voters, are better placed to judge whether an upgrade plan is sound.

    Three more questions for officials and candidates

    Our first post offered four questions about legacy equipment, personal accountability, testing and rollback, and public reporting after outages. The funding request adds three more:

    1. Of the $50 billion requested, how much goes to the communications backbone, and how much to everything else?
    2. Of the $12.5 billion Congress already approved in July 2025, what has been completed, and what remains?
    3. Will the milestones, independent audits, and public reporting described above be written into any funding bill?

    The bottom line

    Should we lay the fiber and the wiring first? Make it the first claim on money and attention, yes. But the larger lesson of November 13 is not about one layer of technology. It is that a known weakness stayed in place until it failed, and that no one could clearly say who was responsible for fixing it. Naming that person, publishing the schedule and reporting the results is how that changes.

    Read the first post in this series, The November 13 Ground Stop: What a Department of Technology Would Have Done Differently, and the third, Build It With the Controllers: The Danger of Rolling Out SMART Without NATCA. For the basics of our proposal, read What Is a Department of Technology? We will update this post as the investigation reveals more.

  • The November 13 Ground Stop: What a Department of Technology Would Have Done Differently

    By the Founders, Department of Technology | San Diego, California | November 14, 2026

    On Friday, November 13, 2026, the FAA grounded flights at every U.S. airport for more than four hours. A future Department of Technology (DoT) would not have run air traffic control, but we believe its structure would have made this failure less likely and the response faster and clearer. This post explains how, and where our proposal has limits. A follow-up post looks at the $50 billion funding request that came next.

    The cause has not been confirmed, and the story is still developing. We rely on published reports and make clear where officials disagree.

    What we know so far

    The FAA said it issued a nationwide ground stop for all U.S. airports after communication issues affected multiple Air Route Traffic Control Centers. According to reporting from NBC News, instability was detected at 3:36 p.m. Eastern, the stop was issued at 3:54 p.m. and lifted at 8:15 p.m., and more than 7,000 flights were canceled. ABC News reported it was only the second nationwide ground stop since 9/11.

    Transportation Secretary Sean Duffy blamed old equipment. NPR quoted him saying, “We have old switches, old routers,” and that the system “got overloaded.” He also said the FAA never lost all radar or communications, and that the stop was a precaution.

    What we do not know

    Officials have not given one consistent explanation. CNN reported that Homeland Security Secretary Markwayne Mullin pointed instead to FAA updates added to the old system. Al Jazeera reported that investigators were examining whether a software update played a role. NPR noted that Duffy did not have a ready answer for why the systems became overwhelmed on an otherwise normal day, and that FAA leaders did not brief reporters. Some air traffic controllers also told reporters they do not accept the explanation, according to CNN.

    We do not claim to know which account is right, and the rest of this post does not depend on it.

    This was not a surprise

    Aging air traffic control technology has been a known problem for years. In January 2023, a failed FAA computer system led to a national ground stop. In 2025, repeated telecommunications failures hit Newark, and Duffy said at the time that “we could see other situations like this around the country because the system is old.” Those problems have spanned administrations of both parties. A known weakness that stays unfixed across years is a structural problem, not only a bad day, and a structural problem calls for a structural answer.

    How a Department of Technology would help

    Our federal framework is a conceptual design, and a DoT would work alongside agencies like the FAA rather than replace them. We see six places where it would have made a difference: four that work before a failure, one during it, and one after.

    1. Making the risk visible before a crisis

    The framework calls for a Technology Oversight Committee that audits operations and reports to Congress, plus regular public reporting. An audit of legacy network equipment across federal agencies would put a known weakness on the record, with a name attached and a deadline, long before it fails.

    2. Putting network expertise at the top

    The official explanation was “old switches, old routers.” Those are the exact tools network engineers work with every day. As we argue in Back to Basics, a leader with hands-on enterprise network experience can judge whether an upgrade plan is sound and whether a vendor’s promise is realistic, which is much harder for someone who has never run a production network. The same logic applies to the network layer that air traffic control depends on, which we examine in our follow-up.

    3. Testing changes before they go live

    If the outage did follow an update, as Mullin suggested, the lesson is about change management. Our framework already requires impact assessments for major technology initiatives. We would go further, with staged rollouts and tested rollback plans for critical systems. That last part is our suggestion and goes beyond the written framework.

    4. Planning for failure

    Grounding flights as a precaution was reasonable, and we are not second-guessing it. The goal is to shrink the time between failure and recovery through redundancy, monitoring, and rehearsed recovery plans. This is the thinking behind our work on continuity of government. Which layer of the system deserves that attention first is the question our follow-up takes up.

    5. Coordinating across agencies

    The framework says cross-agency technology initiatives should be coordinated through the DoT, and it creates a National Technology Security Council for sharing threat information. In the first hours of an outage, the public wants to know whether it is an attack. Shared incident protocols help officials answer that question quickly and consistently.

    6. Telling the public what happened

    Today, the public is hearing competing explanations. We would require a public post-incident report that explains what failed, why, and what will change. That fits our commitment to transparency and public reporting.

    The limits of our proposal

    A Department of Technology would not run air traffic control, and it could not replace aging equipment overnight. Modernization costs real money and takes years. We also cannot promise that it would have prevented this outage, since the cause is not yet known.

    Our claim is narrower: with accountable leaders, hands-on expertise, independent audits, and public reporting, a failure like this becomes less likely, and the response becomes faster and more transparent.

    Questions for officials and candidates

    Whatever the cause turns out to be, these four questions are worth asking:

    1. Which critical systems in your agency still depend on legacy network equipment, and what is the replacement schedule?
    2. Who is personally accountable for the reliability of those systems?
    3. How are major upgrades tested, and how quickly can you roll one back?
    4. Will you commit to a public report after every major outage?

    Our follow-up adds three more, about how the $50 billion request would be spent.

    The bottom line

    The ground stop was a warning, not just an inconvenience. Our airspace, like our schools, hospitals, and power grid, runs on networks that someone must be responsible for keeping up to date. A Department of Technology is our proposal for making sure someone is, and that voters can see how well they are doing.

    Next in this series: Fiber First? The Questions to Ask Before $50 Billion for Air Traffic Control and Build It With the Controllers: The Danger of Rolling Out SMART Without NATCA For the basics of our proposal, read What Is a Department of Technology? We will update this post as the investigation reveals more.