An aviation programme approves an AI budget, the team scopes a deliverable, and eighteen months later the model works in the lab but cannot clear regulatory review. The capability needed super-human reliability in a domain where the cost of failure is unbounded — and nobody asked whether that was feasible before the money was committed. This is the failure mode that quietly burns the most budget in aviation AI: not a model that underperforms, but a programme that was never scoped against the one question that decides everything in this sector. Can the capability you are paying for actually meet certification and regulatory review? In most industries that question can wait until you have a working prototype. In aviation it cannot, because the cost of discovering “no” at the end is the entire programme. We frame aviation AI work feasibility-first for exactly this reason. The point is not to be cautious for its own sake — it is that the regulatory and safety constraints of the domain make the usual build-first instinct structurally wrong here. Where the Build-First Instinct Breaks in Aviation Outside regulated, safety-critical domains, the build-first instinct is reasonable. You scope a deliverable, build it, measure it against a business metric, and iterate. If the first version is mediocre, you improve it. The cost of being wrong is a sprint, maybe a quarter. Aviation breaks this pattern in two ways. First, the acceptance bar is not a business metric — it is certification and regulatory review. A flight-data anomaly detector that catches 95% of events is a strong result by any normal standard. In a safety-critical context, the question regulators ask is what happens with the other 5%, and whether the system’s failure modes are characterised, bounded, and documented. A model that is excellent on average but opaque under edge conditions can be operationally useless because it cannot be certified, no matter how good the headline number looks. Second, the cost of failure is unbounded. In retail, a wrong prediction costs a sale. In commercial aviation operations, the relevant failure scenarios sit at the far end of the consequence spectrum, which is precisely why the regulatory framework demands the reliability and explainability it does. This is not a domain where “ship it and learn” is an acceptable posture for anything touching the safety case. Put those two together and the implication is direct: if you scope an aviation AI deliverable before assessing whether it can clear certification, you are betting the programme budget on an unexamined assumption. That is the failure class. The damage shows up not as a bad model but as months spent on a deliverable that cannot be used. The Early Warning Signs The failure rarely announces itself. It looks like progress until very late. A few signals tend to appear before the wall: The programme charter specifies a model and a target metric, but nowhere states the regulatory pathway the output must satisfy. Accuracy is named; certifiability is not. The plan has one large deliverable at the end. There is no intermediate artifact that could be reviewed, audited, or partially deployed on its own. Conversations about “explainability” and “failure modes” are deferred to a later phase, on the assumption that a working model can be made explainable afterward. For many architectures this is not how it works, and retrofitting interpretability is far harder than designing for it. The capability quietly assumes super-human reliability — a system expected to never miss the cases a human reviewer would also struggle with — without anyone having checked whether the available data supports that bar. When several of these are present, the programme is on a build-first path in a domain that punishes it. The fix is not more engineering effort; it is reframing the scope before more budget is committed. Assessing Certifiability Before You Commit Budget The question that should gate the budget is uncomfortable to ask early because it can return “no.” That is exactly why it has to be asked early. Assessing whether an aviation AI capability can meet certification and regulatory review is a feasibility judgement, and feasibility-first scoping (the consulting posture behind this and other R&D engagements with outcome ownership) puts it first by design. A workable assessment covers four things before the build begins: Feasibility axis Question to answer first Why it gates the budget Regulatory pathway Which certification or review framework must the output satisfy, and what evidence does it demand? Defines the real acceptance bar — usually stricter than the business metric. Reliability bar Does the available data support the reliability the safety case requires, or does it implicitly assume super-human performance? A bar the data cannot reach is a programme that cannot finish. Explainability requirement Can the chosen approach produce the failure-mode characterisation reviewers need? Some architectures cannot be made auditable after the fact. Artifact decomposition Can the work be split so each milestone yields something usable on its own? Protects budget if the full capability proves infeasible. This is a decision rubric, not a model architecture. Notably, none of it is aviation-domain modelling — it is consulting methodology applied to a regulated vertical. The same structure governs how we approach any safety-critical or compliance-bound programme, which is why the discipline travels across regulated verticals rather than being aviation-specific. What Milestone-Based Scoping Looks Like The second half of the answer is structural. Even when a capability is feasible, a single end-of-programme deliverable concentrates all the risk at the point where it is most expensive to discover a problem. Milestone-based scoping spreads that risk by requiring each milestone to produce a usable artifact. Consider a maintenance-scheduling programme as a worked example. The build-first version is “deliver a predictive maintenance model in eighteen months.” The milestone-based version decomposes it: Data and feasibility milestone — a documented assessment of whether the maintenance records support the prediction horizon being asked for. The artifact is the assessment itself, which has standalone value: it either green-lights the build or saves the remaining budget. Anomaly surfacing milestone — a system that flags unusual patterns for human review, deployable on its own without making autonomous decisions. The artifact is a working triage aid. Validated prediction milestone — the predictive model, now built on a feasibility judgement that already cleared the regulatory pathway, with explainability designed in rather than retrofitted. Each step produces something the programme can use even if the next step stalls. That is the ROI anchor: every milestone yields a usable artifact rather than a single deliverable that may not pass review. In our experience across regulated work, this is also what keeps stakeholders aligned, because progress is legible at each stage rather than invisible until the end. (This is an observed pattern across engagements, not a benchmarked rate.) The same logic underpins narrower aviation applications — for instance, the role of visual evidence in aviation compliance, where the documentation artifact at each stage is itself the deliverable that has to satisfy review, not a byproduct of it. Structuring the Risk Assessment Feasibility framing and milestone decomposition come together in an explicit risk assessment performed before the build commitment. The aim is to make the unbounded-cost-of-failure character of the domain visible at the point of decision, not after. A structured risk assessment for an aviation AI programme names, for each candidate capability: the regulatory pathway and its evidence demands, the reliability bar implied by the safety case, the explainability the chosen approach can and cannot provide, and the decomposition into independently usable milestones. Where any of these resolves to “infeasible” or “unknown,” that is a finding to act on before budget moves — which is precisely why explicit risk structuring belongs at the front of an aviation programme rather than buried in a later phase. Where does feasibility-first scoping matter most? Wherever the deliverable touches the safety case directly. Maintenance scheduling, flight-data analysis, and compliance documentation each carry different review burdens; a capability that informs a human decision is a different feasibility problem from one that the safety case depends on. The role AI plays in aviation safety is real, but it is bounded by what can be certified — and that boundary is a feasibility question, not an engineering one. Related work on AI’s contribution to flight safety standards and predictive aviation maintenance lives inside this same constraint. FAQ What is generative AI in aviation? In aviation, generative AI refers to model-generated content and analysis — for example drafting compliance documentation or summarising flight-data patterns. The decisive issue is not the technique but whether its output can clear certification and regulatory review, which is why we frame any such capability feasibility-first before scoping a build. What is AI in aviation maintenance? AI in aviation maintenance typically means using historical maintenance and sensor data to surface anomalies or predict component issues before failure. The feasibility question that gates it is whether the available records actually support the prediction horizon being asked for, and whether the system’s failure modes can be characterised well enough to satisfy review. How do you assess whether an aviation AI capability can meet certification and regulatory review requirements before committing budget? Assess four axes before the build: the regulatory pathway and the evidence it demands, the reliability bar the safety case implies, the explainability the chosen approach can produce, and whether the work decomposes into independently usable milestones. Any axis that resolves to “infeasible” or “unknown” is a finding to act on before budget moves, because discovering it at the end costs the whole programme. What does milestone-based scoping look like for an aviation AI programme, and how does each milestone produce a usable artifact? It decomposes a single end-of-programme deliverable into stages where each milestone yields something the programme can use on its own — a documented feasibility assessment, a human-review triage aid, then a validated model. The point is that if a later stage stalls, the earlier artifacts still have standalone value, so risk is spread rather than concentrated at the most expensive moment to discover a problem. How should an aviation programme structure an AI project risk assessment before committing to a build? For each candidate capability, name the regulatory pathway and its evidence demands, the reliability bar from the safety case, the explainability the approach can and cannot provide, and the decomposition into independently usable milestones. Performing this before the build commitment makes the unbounded-cost-of-failure character of the domain visible at the point of decision rather than after. What role does AI play in aviation safety, and where does feasibility-first scoping matter most for safety-critical deliverables? AI’s role in aviation safety is real but bounded by what can be certified, so feasibility-first scoping matters most wherever a deliverable touches the safety case directly — maintenance scheduling, flight-data analysis, and compliance documentation each carry different review burdens. A capability that merely informs a human decision is a different, lighter feasibility problem than one the safety case itself depends on. A Question Worth Asking First Before the next aviation AI budget is approved, the gating question is not “can we build it” — modern tooling makes a great deal buildable. It is “can what we build be certified, and does each milestone leave us with something usable if the answer turns out to be no.” A programme that cannot answer those before committing is exposed to the one failure this domain punishes hardest: an end-of-programme deliverable that cannot pass review. Structuring an explicit project risk assessment at the front, rather than discovering the constraint at the end, is the difference between a feasibility judgement and an expensive one.
