Wayfinder and the Requirements Behind the Algorithm

How an aviation AI company engineers safety cases for AI-generated flight routing in FAA-regulated operations

The Problem Is Not the Algorithm

Wayfinder — formerly Airspace Intelligence — builds AI-augmented flight operations tools for commercial airlines and cargo carriers. Their core product generates dynamic flight routing recommendations that account for weather, airspace congestion, fuel burn optimization, and cost index targets. Airlines including Alaska Airlines have used these tools operationally, with reported fuel savings in the range of millions of pounds annually across fleet deployments.

The engineering achievement is real. But the harder problem — the one that does not appear in press releases — is not building an algorithm that generates good routes. It is specifying, verifying, and maintaining the requirements that govern when and how that algorithm’s output is permitted to influence a flight operation under FAA oversight.

That problem is a systems engineering problem, and it is substantially unsolved at the industry level.

What Wayfinder Actually Builds

The product sits in what the aviation industry calls the advisory layer. Wayfinder’s system does not command aircraft. It does not interface with flight management computers directly during flight. It generates pre-departure and in-flight route modification recommendations that are delivered to dispatchers and flight crews through existing airline operations infrastructure — typically the Aircraft Communications Addressing and Reporting System (ACARS) and airline operations control center (OCC) displays.

This positioning is not accidental. It is a deliberate regulatory and safety architecture choice. By remaining advisory — by keeping a human dispatcher or flight crew as the decision authority — Wayfinder avoids the certification burden that would apply to a system with direct control authority. The AI does not fly the plane. The AI tells a qualified human what it thinks the plane should do, and that human decides.

This distinction is the load-bearing wall of the entire safety case.

The practical implication is that Wayfinder’s requirements engineering challenge is not primarily about certifying the model. It is about certifying the interface — specifying exactly what the advisory system is permitted to say, how it must say it, when it is suppressed, and what human decision process must be in place to receive it.

Three Requirements Domains That Do Not Naturally Connect

For most software products, requirements live in a single domain: the software does X when the user does Y. For aviation AI advisory systems, requirements span at least three distinct domains simultaneously, and the interactions between them are where the engineering risk concentrates.

Software requirements cover the expected behavior of the recommendation engine itself: latency bounds on route generation, output format conformance, handling of data dropouts, graceful degradation when upstream weather data is delayed or corrupted. These map relatively cleanly to standard software verification practices, including the DO-178C guidance the FAA uses for airborne software — though Wayfinder’s system, operating ground-side in the OCC, is not itself subject to DO-178C. The spirit of the guidance still informs how serious teams approach the problem.

Data requirements are more complex. A routing recommendation is only as good as its inputs: National Weather Service model data, FAA Traffic Flow Management System feeds, airline cost index parameters, aircraft performance models specific to tail number and configuration. Each of these data sources has its own latency characteristics, update cadence, known error modes, and provenance. A requirement on the AI system’s output is implicitly a requirement on the data pipeline feeding it — but those requirements are often held by different teams, tracked in different tools, and governed by different change control processes.

This is where requirements traceability breaks down in practice. A change to how the airline’s OCC ingests weather model data — a purely infrastructure-level change managed by the airline’s IT team — can invalidate assumptions baked into the routing algorithm’s training data distribution without triggering any review of the AI system’s requirements. The traceability link does not exist because the organizational boundary does not invite it.

Operational procedure requirements are the third domain, and arguably the most underspecified in the industry. These are the requirements that govern human behavior in the decision loop: what a dispatcher must verify before accepting a Wayfinder recommendation, what phraseology is used to communicate a reroute suggestion to the flight crew, what the crew’s obligation is to assess the recommendation against their own situational awareness. These requirements live in airline operations specifications (OpSpecs), dispatch procedures, and crew training syllabi — documents that are owned by the airline, not by Wayfinder, and regulated by the FAA through a different approval pathway than software.

The gap between software requirements and operational procedure requirements is where liability concentrates in accident investigation. When an AI-advisory-influenced decision leads to an incident, the question becomes: was the failure in the algorithm’s output, in the data that fed it, or in the human procedure for evaluating it? If those three domains are not traced to a common requirements baseline, that question may not have a clean answer.

The Safety Case Architecture: Bounding the Envelope

The regulatory framework Wayfinder operates within — primarily FAA Advisory Circular 20-115 for software considerations and the broader Part 121 operational approval process — was not designed with learned-model AI systems in mind. DO-178C, the dominant software certification standard for avionics, assumes deterministic software: given input X, the software produces output Y, and you can verify that relationship exhaustively. A neural network trained on historical routing data does not work this way.

The industry response to this mismatch has been to focus safety cases on the advisory envelope rather than the model internals. Rather than certifying that the algorithm always produces correct routes — which is not achievable with current standards for learned models — the safety case bounds what the algorithm is permitted to recommend. Route changes are constrained to airspace and altitude bands that are operationally plausible. Fuel-burn projections are flagged if they deviate beyond a specified percentage from the aircraft’s own fuel management system estimate. Recommendations are suppressed entirely within defined proximity to departure or in airspace categories where dynamic routing changes carry elevated risk.

This is requirements engineering doing the work that model certification cannot yet do. The requirement is not “the model must be correct.” The requirement is “the model’s output must fall within a bounded envelope such that an error within that envelope is recoverable by the human decision authority in the available time.”

This approach is functional, but it is conservative. It limits how aggressive Wayfinder’s routing optimizations can be in practice, because the more novel and high-value a recommendation, the harder it is to bound its failure mode. The fuel savings the system generates come largely from the cases that are well within the safe advisory envelope — not from the edge cases where the algorithm might offer the most insight.

The Organizational Requirements Problem

Wayfinder sells to airlines. Airlines are large, complex organizations with their own IT infrastructure, their own regulatory relationships with the FAA, and their own operations control cultures built over decades. Deploying an AI advisory system into this environment means requirements that Wayfinder writes must ultimately be implemented, maintained, and verified by people and organizations that Wayfinder does not control.

This creates a class of requirements that systems engineers sometimes call “shall be implemented by” requirements — requirements on the integrating organization, not on the product itself. Wayfinder’s deployment documentation must specify, clearly and verifiably, what the airline must do to maintain the validity of the system’s safety case: data feed update cadences, dispatcher training currency, OCC display configuration, escalation procedures when the recommendation engine is degraded.

If those requirements are written as prose in an integration manual, they are difficult to trace, difficult to verify at deployment, and nearly impossible to maintain across software updates and airline procedure revisions. The airline’s operations engineering team, the dispatcher training group, and the IT infrastructure team will each receive a different section of that integration manual — and none of them will have visibility into the requirements held by the other two groups, or how a change in one domain affects the validity of requirements in the others.

This is the exact failure mode that structured, model-based requirements management exists to prevent. The aviation AI industry is learning this lesson in production, which is a more expensive classroom than most.

What Good Requirements Practice Looks Like Here

The teams handling this problem most effectively share several practices, regardless of what toolchain they are using.

They maintain explicit domain tagging on every requirement — software, data, or operational procedure — so that a change in any one domain triggers a review of the requirements it touches in the other two. This sounds obvious, but it requires deliberate schema design in the requirements management system, not just naming conventions in a document.

They treat data provenance as a first-class requirements concern. Every AI-generated output should be traceable to the data sources that informed it, and requirements on those data sources should be version-controlled alongside requirements on the software that consumes them. When the National Weather Service changes a model output format, that change should propagate through the requirements system as a potential impact event, not disappear into an IT ticket.

They write operational procedure requirements in verifiable language. “Dispatchers should review the recommendation” is not a requirement. “The dispatcher shall compare the recommended routing to the filed flight plan using the OCC display verification checklist before transmitting to the aircraft” is a requirement — one that can be audited in training records and incident reviews.

And they maintain a live requirements traceability structure that spans the software-data-procedure boundary, so that when any change occurs in any domain, the impact on the safety case is visible before the change is deployed, not after an incident investigation reveals it.

Modern requirements platforms that treat requirements as connected nodes in a graph — rather than rows in a document — are substantially better suited to this cross-domain traceability problem than legacy document-based toolchains. The ability to traverse a requirement from its source rationale through its implementation in code, its dependency on a specific data feed version, and its corresponding operational procedure without losing the thread is not a convenience feature in aviation AI. It is an architectural necessity.

An Honest Assessment

Wayfinder is doing genuinely difficult engineering. The operational fuel savings are real, the advisory architecture is well-reasoned for the current regulatory environment, and the team understands the domain deeply. The challenge they face — specifying and maintaining requirements across software, data, and human procedure domains for an AI system operating in a regulated environment — is not a problem of their making. It is the central unsolved problem of deploying AI in regulated industries, and aviation is living at the hard edge of it.

The FAA’s regulatory framework will continue to develop. EASA in Europe is somewhat ahead of the FAA on AI-specific guidance frameworks, and their work will likely inform U.S. rulemaking over the next few years. But regulatory guidance is a lagging indicator. The companies deploying AI advisory tools in operations today are writing the failure histories that the next generation of guidance will be written to prevent.

The engineering teams that will navigate this period most effectively are the ones that invest now in cross-domain requirements traceability — not because a regulator requires it, but because it is the only honest way to know whether your safety case is actually intact. For a system where the human is the last line of defense, knowing what you don’t know is not optional.