Everyone's arguing about the ceiling. They already agree on the building.

What the EASA AI Concept Paper Issue 03 consultation is really exposing — checked against the 239-page document itself.

With the comment window on EASA's AI Concept Paper Proposed Issue 03 closing on 12 August 2026, the two most substantive public submissions come from opposite corners: an airline-operations software startup and an aerospace-certification analyst. They read like a clean disagreement. Read the actual document they are arguing about, and they turn out to be describing the same aircraft from different seats.

This piece takes both critiques and checks them against the primary text — the 239-page Proposed Issue 03 guidance itself, not the press summaries.

The two submissions

Overwatch AI, which builds retrieval-augmented decision-support for airline operations, says it filed 30 comments — six of them asking EASA to be stricter than it proposes. Its central objection: the framework rewards traceability over demonstrated capability. It singles out the LLM assurance cap as resting on a requirement no large model can meet, argues that retrieval-augmented systems deserve their own rules, and insists the paper wrongly addresses a single "applicant" when reality has four parties — foundation lab, vendor, airline, end user.

Swiss Aerospace Ventures, through analyst Julian Walder, takes what looks like the opposite line in two articles. The assurance ceiling is fine: learned systems genuinely lack the requirements-to-code traceability that the highest assurance levels are built on, so capping the trust placed in them is an honest engineering diagnosis, not an arbitrary limit. His advice is to stop fighting it and architect around it — let the AI do perception at the capped level, and put a deterministic, auditable decision layer above it. In a companion piece he warns that over-building explainability against a provisional specification risks becoming "certification theatre."

What the document actually says

The ceiling is real, and it is a table. Issue 03's Table 2 (p. 24) sets hard assurance-level ceilings by AI technique: supervised learning, reinforcement learning and logic-/knowledge-based ("symbolic") AI top out at IDAL C; unsupervised learning and "large OTS models" — off-the-shelf models including general-purpose LLMs — are limited to IDAL D, the lowest tier. Separately (p. 20), an AI constituent involved in catastrophic failure conditions "will not be accepted," and reduction below DAL D is not acceptable either. So the best a learned component can be assured to is IDAL C, LLMs sit a rung below at IDAL D, and no learned AI may carry a catastrophic-failure safety case at all. The "DAL C ceiling" is not analyst shorthand; it is in the table.

The LLM cap really does rest on an impossible requirement — and EASA says so first. Overwatch's sharpest technical claim is that the LLM ceiling hangs on Objective RU-02, which requires an analysis of a model's "unused functions" and their deactivation (pp. 112, 170) — something you cannot do to a model with billions of parameters. The document does not dispute this. It states it. The note on large OTS models on p. 112 reads that for general-purpose LLMs "the number of parameters (billions or trillions) and the nature of the training data render the fulfilment of Objective RU-02 and the control of the design process intractable. Therefore … the use of large OTS models is only warranted for assurance levels AL5/SWAL4/DAL D."

Read that carefully, because it dissolves half the argument. Overwatch is right that the requirement is unmeetable — but EASA is not pretending otherwise and quietly failing. It is using the intractability as the stated reason for the DAL D cap. That is precisely Walder's "honest diagnosis" position, written into the paper: we cannot assure the internals, so we cap the trust. The disagreement that remains is narrower and more interesting than "the cap is broken." It is: should a ceiling be derived from what you cannot trace (EASA and Walder) or from what you can demonstrably contain (Overwatch)?

The wrapper is mandatory. For Level 3 "advanced automation," Issue 03 requires, in line with EU AI Act Article 14, an independent "operational oversight system" that continuously monitors the AI's performance and safety and can alert or intervene when it drifts outside its operational domain (pp. 146, 144). That is the deterministic, auditable layer both critics recommend — Overwatch's cited-source retrieval and Walder's "decision layer above the perception" are the same Swiss-cheese slice drawn twice — and EASA has made it a requirement, not a suggestion. On architecture, the regulator has already sided with the wrapper.

On "four parties, not one," the paper is better than its critics allow — but not all the way. The technical assurance objectives are indeed written to a single "applicant." But Section 5.3 (pp. 150–151) requires a Level 2B/Level 3 "responsibility scheme" (Objective RS-01) that allocates responsibility for every high-level task and scenario explicitly across provider, deployer and end user, with three named guardrails: no responsibility assigned to the AI itself ("a tool … not a legal entity"), no gaps, and no "responsibility dumping" onto a party without the authority or means to fulfil it. So the multi-party chain is not missing — it is a named objective. What Issue 03 does not cleanly resolve is where an upstream foundation-model lab sits: the "provider" is defined as the party with "effective control over the AI-based system design," which a general-purpose LLM vendor arguably does not have over any given downstream use. The precise, defensible version of Overwatch's critique is not "responsibility is unallocated" — it is "the provider/deployer/end-user schema does not map onto the foundation-lab-to-integrator reality."

And Overwatch's RAG point survives contact with the text. Search the 239 pages and "retrieval-augmented" appears exactly zero times; "retrieval" appears four times, incidentally. A system whose governance comes from versioned documents, auditable retrieval and explicit citations is, under Issue 03, assured as just another "large OTS model" at DAL D — the mechanism that most distinguishes it is invisible to the framework. That is a real gap, and it is the strongest thing Overwatch says.

(One correction to the surrounding commentary: "automation bias," central to Walder's explainability critique, is a human-factors term he brings to the paper — it does not appear in Issue 03. Explainability itself very much does: 128 mentions and its own Section 5.4. His point stands, but as an outside argument, not a quote.)

The two questions that are actually open

Once you see the convergence, the unresolved issues get sharper:

1. What counts as evidence for a system you cannot fully trace? Classical aviation assurance means requirements-to-code traceability. Learned systems break that thread. EASA's answer — cap the trust, wrap it in an independent oversight system — settles the architecture but not the evidence standard; the binding means of compliance still sits downstream in rulemaking (RMT.0742). Whether demonstrated operational containment can ever substitute for traceability is the live question, and it is the one that decides what actually ships.
2. Where does the foundation-model lab sit? The responsibility scheme cleanly handles provider, deployer and end user. It does not cleanly handle the party that trained a general-purpose model it does not control the downstream use of. That is the gap most likely to produce real disputes — and, notably, the same fragmentation others have flagged from the FAA-harmonisation side.

The operator's takeaway

Cut through the DAL letters and the useful signal is this: the safe architecture is not in dispute. A deterministic, auditable layer wrapping the AI, independently monitored, with responsibility explicitly allocated to real people — that is what both critics recommend and what Issue 03 now requires. It is buildable today, at Level 1, whatever number the ceiling settles on. The fight is over how you evidence that system, not what shape it should be. So the operators who start capturing operational-containment evidence and a documented responsibility scheme now are the ones who will be ready when the evidence standard finally lands.

Primary source: EASA, Concept Paper: Guidance for the use of Artificial Intelligence — Proposed Issue 03 (June 2026), 239 pp. Page citations above refer to that document. Table 2, p. 24 (assurance-level ceilings); p. 20 (catastrophic-failure limit); pp. 112 & 170 (Objective RU-02 and the large-OTS/LLM "intractable" note); pp. 144 & 146 (independent operational oversight system, EU AI Act Art. 14); pp. 150–151 (Objective RS-01 responsibility scheme).

Commentary cited: Overwatch AI — Our thoughts on EASA's proposed AI guidelines · Swiss Aerospace Ventures — the DAL C ceiling · Swiss Aerospace Ventures — explainability as certification theatre · JDA Solutions — does EASA's AI initiative require an FAA response