EASA SC Light-UAS and SC-VTOL: means of compliance with AI

A means of compliance with an objective-based special condition is the document that says how a paragraph of the condition applies to your configuration, which auditable or measurable specifications your design will meet, and how compliance will be shown. EASA's two special conditions for new aircraft categories, SC Light-UAS for unmanned aircraft in the specific category and SC-VTOL for person-carrying VTOL aircraft, set safety and design objectives rather than prescriptive requirements, so the means of compliance and the table that holds them are where most of the certification work is. This guide sets out what the two conditions cover, how the SORA decides whether a UAS needs a statement of compliance, a design verification report or a type certificate, what a proposed means of compliance must contain, what the DVR application asks for, seven steps to build the table and the evidence, and which of those steps an AI teammate can draft.

Two objective-based special conditions

Both conditions come from the same decision. EASA's introductory note to SC Light-UAS explains that the certification basis of unmanned aircraft had previously been derived from manned aircraft specifications with special conditions, or from JARUS documents, and that both approaches were prescriptive; objective-based specifications were judged more appropriate, and the condition is applied under point 21.B.80 where no certification specification exists. The methodology section names the inputs: the JARUS CS-UAS, earlier EASA RPAS special conditions and SC-VTOL, the latter two based on CS-23 Amendment 5, with the design-related OSOs of the SORA taken into account. SC-VTOL's statement of issue says the same of VTOL aircraft: no certification specification fitted, so a complete set of objectives was written as a special condition, following the CS-23 Amendment 5 approach so as not to limit innovation.

One design decision in SC Light-UAS shapes the whole table. The condition ties every certification to a characterisation of the operational volume, the buffers and the adjacent volumes in terms of ground and air risk, with the restrictions, limitations and mitigation means assumed for the operation, and says the type certificate issued on that basis will only permit operations in that context. Mitigation means linked with the design and claimed in the SAIL determination are subject to compliance demonstration under the condition; mitigation means not linked with the design are not verified in the type certification but are discussed under Light-UAS.2005 and may become airworthiness limitations.

Which route the SORA decides

The route is set in AMC1 to Article 11 of Regulation (EU) 2019/947, which since ED Decision 2025/018/R carries SORA 2.5. For an operation classified as SAIL I, II or III the competent authority may accept, as part of the operational authorisation, a statement of compliance from the designer of the UAS or of a component with all design-related OSOs and mitigations. For SAIL IV, compliance with the design-related requirements of the SORA, the design-related OSOs, the mitigations linked with the design and the containment function, should be demonstrated through a design verification report issued by EASA. For SAIL V and VI it should be demonstrated through a type certificate under Part 21. Regardless of the SAIL, when mitigation M2 or containment is claimed at high robustness, the authority should require a UAS with a DVR limited to those requirements.

The DVR guidelines add what the report is and is not. The service gives the applicant an independent assessment of the design-related OSOs, the mitigation means and the enhanced containment, on which the national authority can rely; the scope can cover the full design, the mitigation means, the enhanced containment function, or parts installed on a UAS that contribute to its safety performance. EASA issues a no-technical-objection for the verified domains and does not certify or approve the unmanned aircraft, the command unit or the operation, and it will not approve the SORA: the SORA is used to define, in the report, the limitations the operator will carry into the application for an operational authorisation. For a VTOL aircraft there is no such intermediate route; the category, Basic or Enhanced, is chosen under VTOL.2005 and the aircraft is type certified.

What a means of compliance must contain

Because the conditions are objective-based, the DVR guidelines say the means of compliance have to do three things: describe how the paragraph applies to the UAS configuration, specify concrete design-related specifications that can be audited or measured, and define how compliance with those specifications will be demonstrated, by design review, calculation or analysis, laboratory test, ground test or flight test. They can come from three places: the MoCs EASA has published, published technical specifications or industry standards with their relevant sections, or a new proposal where neither is appropriate. A proposed MoC that does not simply apply a published one must state at least five things.

• The design objective that is to be achieved.
• The activities to be carried out and their planning.
• The parameters considered relevant and their rationale.
• The references to industrial standards, airworthiness specifications or other AMC and GM, if any.
• The pass/fail criteria.

The published MoCs show what EASA expects of the result. MOC Light-UAS.2510-01, for SAIL IV, states that Light-UAS.2510 specifies the technical safety objectives derived from OSO #5 and OSO #10/#12 of the AMC and GM to Regulation (EU) 2019/947, that it applies to every system on which compliance with a flight, structural, lift/thrust/power, C2 link or remote crew interface requirement depends, and that it does not cover cybersecurity, qualification such as HIRF and EMI, or artificial intelligence technologies, which may require a particular compliance demonstration. The functional-test-based MoC of May 2022 offers extensive functional test evidence as the means for a large subset of the condition, acceptable for SAIL III and below. On the VTOL side, MOC-2 SC-VTOL Issue 3 alone carries means for more than thirty paragraphs from VTOL.2105 to VTOL.2625, and EASA's note that some of that material is guidance to help understand the objective rather than a defined means is a warning that the applicant's own MoC still has to be written.

The columns of the means-of-compliance table

The table is the compliance checklist of the certification programme, or of the design verification programme, with the columns the objective-based approach needs.

• Paragraph and sub-paragraph of the special condition, with the issue in the header; special conditions under 21.B.75 in the same series.
• Applicability to the configuration, with a rationale for every paragraph that does not apply.
• Design objective as it applies, in the applicant's words, and the measurable specification the design will meet.
• Source of the MoC: published EASA MoC by number and issue, standard and section, or proposed.
• Activities and their planning, and the pass/fail criteria.
• Compliance document, by number and issue.
• What it serves: for a Light-UAS project the OSO, mitigation means or containment requirement of the SORA the row answers; for a VTOL project the category the objective applies to.
• Owner and status, with a column for EASA's comments.

Seven steps to build the table and the evidence

1. Fix the operation before the design basis. For a UAS in the specific category the DVR guidelines ask first for the typical operation, its assumptions and limitations, the environmental and operational conditions, the buffers and corridors, any credit claimed for ground or air risk mitigation and whether enhanced containment is needed, and then for a representative SORA. The SAIL that comes out of it decides whether the design needs a statement of compliance, a DVR or a type certificate, and which design-related OSOs and mitigations the basis has to answer. For a VTOL aircraft the equivalent decision is the category: Enhanced if the aircraft will fly over congested areas or carry passengers commercially, Basic otherwise.
2. Establish the design verification basis or the certification basis. List the paragraphs of the special condition that apply to the configuration, one row each with a rationale for every paragraph that does not apply, and add any special condition prescribed under point 21.B.75 for a novel feature. For a Light-UAS project the basis also records the design-related mitigation means claimed in the SORA, because the SC says those are subject to compliance demonstration, and any equipment the operation requires, which is installed to Subpart F. For a VTOL project the basis records the category and the applicable amendment of SC-VTOL.
3. Choose the source of each means of compliance. The DVR guidelines allow three sources: the MoCs EASA has published, a published technical specification or industry standard with the relevant sections named, or a new MoC where neither fits. Take the published MoC where one exists, since it is what the certification experts will compare a proposal to, and record for each row which of the three it is. Under VTOL.2010 an applicant must use means of compliance accepted by EASA, which may include consensus standards, and must submit any other means for acceptance.
4. Write each proposed MoC to the five minimum items. For every row that is not covered by a published MoC, the DVR guidelines require the design objective to be achieved, the activities to be carried out and their planning, the parameters considered relevant and their rationale, the references to industrial standards, airworthiness specifications or other AMC and GM, and the pass/fail criteria. The guidelines' own example for Light-UAS.2235 shows the shape: define the flight envelope under Subpart B, choose and justify the margin between limit loads and failure, estimate the loads at the critical points, apply the ultimate loads in a test, and state what passes.
5. Keep the assessment qualitative until it has to be quantitative. The guidelines say that the low and medium risk levels of the specific category, SAIL I to IV, rely mainly on qualitative requirements, that a quantitative approach may be disproportionate and may shift the focus away from the safety objective, and that a safety analysis should start qualitative and turn quantitative only when the qualitative assessment is not conclusive. The published MoC to Light-UAS.2510 for SAIL IV sets the safety objectives the assessment has to meet; the high-risk SC and its MoC for SAIL V and VI move to the extremely improbable, extremely remote and remote objectives that a type certificate requires.
6. Assemble the design verification programme or the certification programme. The DVR application needs the detailed description of the design and the configurations to be verified, the SORA and the description of the typical operations with the operating characteristics and limitations, the design verification basis, the design verification programme with the list of MoCs and the related compliance documents, and a project schedule. The programme is the document the applicant and EASA manage the evolving design and the compliance demonstration from, so it carries the MoC table and is revised with it. A type certification project carries the same content in the certification programme under point 21.A.15(b).
7. Run the verification, close the rows, and read the report for what it is. Once the programme is agreed, the applicant conducts the appraisals, analyses and tests and documents them against the pass/fail criteria, one compliance document per row or group of rows. The outcome of a design verification is a report stating that EASA is satisfied with the verified compliance demonstration, with the limitations, conditions and assumptions under which it holds, drawn from the SORA. It is a no-technical-objection for the verified domains; it does not certify or approve the unmanned aircraft, the command unit or the operation, and EASA does not approve the SORA. The applicant retains the design data, drawings and test reports that keep the report valid.

What AI can draft and what the engineer decides

An objective-based condition moves work from reading requirements to writing means, and most of that writing is derivation from documents the organisation already holds: the condition, the published MoCs, the standards it uses, the SORA and the design description. A language model that works only from those, and cites the paragraph or the MoC section behind every proposal, can produce the table and the first draft of each proposed means. The margins, the criteria and the classifications are engineering decisions.

The conditions that make this safe are the ones in Can AI be trusted for aviation compliance documentation?: a corpus limited to the condition, the MoCs and the standards at their current issue, citations at paragraph level, a boundary on who may change the corpus, and a review record. The safety assessment itself, and why the classification of a failure condition stays with the engineer, is covered in the guide on functional hazard assessment with AI; the civil compliance matrix that this table extends is in the guide on the certification-basis compliance matrix.

Five mistakes that produce findings

• A prescriptive MoC copied from a manned-aircraft programme. The condition asks for the objective as it applies to this configuration; a CS-23 substantiation method carried over unchanged answers a different paragraph.
• Quantitative analysis where the guidelines ask for qualitative. For SAIL I to IV the guidelines warn that a quantitative approach may be disproportionate and shift the focus away from the safety objective. Start qualitative.
• A SORA that claims what the design basis does not carry. A mitigation linked with the design and claimed in the SAIL is subject to compliance demonstration; if it has no row, the report will not cover it and the operator's authorisation will not rely on it.
• Treating the DVR as an approval. It is a no-technical-objection with limitations from the SORA. Marketing the aircraft as certified on the strength of it is a finding of a different kind.
• A proposed MoC without pass/fail criteria. Four of the five items describe an activity; the fifth is what lets EASA and the applicant agree that the objective was met. Without it, the row cannot close.

How Wingman360 Teammate builds one

The compliance-matrix workflow in Wingman360 Teammate starts from the special condition at its current issue, the published MoCs, the standards the organisation uses, the SORA and the design description that its administrators have ingested. It enumerates the paragraphs, proposes applicability and the source of each means with a citation into the document, drafts the five items of every proposed means and the design verification programme or certification programme around them, and produces the table for engineering review. Engineers set the margins, the criteria and the classifications, accept, edit or reject every row, and the declaration is theirs. The same approved knowledge base answers questions from the condition and the MoCs during the project. Each deployment is a dedicated single-tenant instance in the organisation's own cloud or on-premise, with a local model option so that no design data leaves the network. What else it drafts for a UAS programme is on the UAS manufacturers and operators page.