SORA 2.5 with AI: the ten steps, the UAS operations manual

A specific operations risk assessment is the process by which a UAS operator shows that an operation in the specific category is acceptably safe: it describes the operation, classifies its ground and air risk, applies mitigations, derives a specific assurance and integrity level, and from that level the operational safety objectives, the containment requirement and the evidence the operator must produce. EASA adopted the JARUS methodology, version 2.5, as AMC1 to Article 11 of Regulation (EU) 2019/947 by ED Decision 2025/018/R. It runs in ten steps and two phases, and it ends in two documents the competent authority reads before it issues an operational authorisation: the comprehensive safety portfolio and, when the risk and complexity require one, the operations manual. This guide sets out what the regulation requires, what each step decides and produces, what the portfolio and the manual must contain, seven steps to get from a concept of operations to an application, and what an AI teammate can draft while the claims, the robustness and the application stay with the operator.

What the regulation requires

Article 11 of Regulation (EU) 2019/947 requires an operational risk assessment to describe the characteristics of the operation, propose adequate operational safety objectives, identify the risks on the ground and in the air, identify a range of possible mitigating measures and determine the robustness those measures need so that the operation can be conducted safely. The description must cover the nature of the activities, the operational environment and geographical area including the overflown population, the airspace and the risk buffers, the complexity of the operation, the technical features of the UAS and the competence of the personnel; the assessment must propose a target level of safety equivalent to manned aviation.

Point UAS.SPEC.030(3) lists what the application for an operational authorisation adds to the risk assessment: the operator's registration number, the name of the accountable manager, the operational risk assessment, the list of proposed mitigation measures with enough information for the authority to assess them, an operations manual when required by the risk and complexity of the operation, and a confirmation of insurance where required. Point UAS.SPEC.050 places on the operator the duty to establish procedures and limitations adapted to the operation, to designate a remote pilot for each flight, and to ensure that remote pilots and other essential personnel have been informed of the operations manual where the risk assessment requires one. The SORA is how the assessment in Article 11 is done; the AMC states the target level of safety it is built on as fewer than one ground fatality per million flight hours and fewer than one mid-air collision per ten million flight hours under self-separation.

The ten steps, and what each one produces

Section 0 of the AMC describes the methodology as ten systematic steps, and Section 3 splits them into two phases: Phase 1, Steps #1 to #9, derives the safety requirements and the proposed means of compliance; Phase 2, Step #10, shows compliance with them. The AMC recommends reaching an in-principle agreement with the competent authority at the end of Phase 1 on the final ground risk class, the residual air risk class and the SAIL, so that the operation, the procedures and the design are not reworked after the evidence has been produced.

The design route follows from the SAIL. Under the same AMC an operation at SAIL I, II or III may rely on a statement of compliance from the designer of the UAS with the design-related objectives and mitigations; at SAIL IV the design-related requirements are shown through an EASA design verification report; at SAIL V and VI through a type certificate. The design side of that route, the special conditions and the means of compliance, is covered in the guide on SC Light-UAS and SC-VTOL means of compliance.

The seventeen operational safety objectives

Annex E defines the objectives and, for each SAIL, the robustness required. The AMC groups them by what they address: the operator and the other organisations involved, the design and production of the UAS, technical aspects, deterioration of external systems, the human-machine interface, human error and adverse operating conditions. In the SORA 2.5 numbering, which keeps gaps where earlier objectives were merged, they are:

• OSO #01 the UAS operator is a competent and/or proven organisation; #02 the UAS is designed and produced by a competent and/or proven organisation; #03 UAS maintenance; #04 components essential to safe operations are designed to an airworthiness design standard; #05 the UAS is designed considering system safety and reliability.
• #06 C3 link characteristics are appropriate for the operation; #07 conformity check of the UAS configuration; #08 operational procedures are defined, validated and adhered to; #09 the remote crew is trained and current.
• #13 external services supporting the operation are adequate; #16 multi-crew coordination; #17 the remote crew is fit to operate.
• #18 automatic protection of the flight envelope from human errors; #19 safe recovery from human error; #20 a human factors evaluation has been performed and the HMI found appropriate.
• #23 environmental conditions for safe operations are defined and measurable; #24 the UAS is designed and qualified to operate in adverse environmental conditions.

Each objective is answered by a document: the operations manual for the procedural ones, training records for the crew ones, the designer's statement, verification report or certificate for the design ones. The compliance matrix in Annex A chapter A.4 is where the operator says which document answers which objective, at which robustness, and the AMC is explicit that the matrix is a reference to where the evidence can be found, not the evidence itself.

The operations manual

Annex A chapter A.3 gives a recommended structure for the operations manual, and states that while the structure is not mandatory, the topics it contains should be incorporated as needed for the operation to provide the information and evidence required. After the cover, document control, applicable documents, purpose and scope and definitions, it has six parts.

• Part A, General: opening, security and privacy and environmental statements; the operating organisation with its chart and the duties of personnel; change management, retention periods and document control; requirements and qualifications for remote pilots, maintenance, ground and training personnel; fitness for the operation, preventive health care and duty and rest periods.
• Part B, Procedures: multi-crew coordination; flight planning with up-to-date information and geographical zones; external services and systems; obtaining and evaluating weather and responding to unexpected weather; the procedures for the tactical mitigation performance requirements; occurrence reporting; and, per UAS type, the normal, contingency and emergency procedures.
• Part C, Flight areas: general operational and technical limitations, then per flight area the description, the calculation of the contingency volume and ground risk buffer, the specific procedures and the local emergency response information.
• Part D, Training, and Part E, the emergency response plan: its creation, template, preparation and briefing, and the reporting obligations after an emergency.
• Part T, the technical part per UAS type: description, C3 link, parachute where M2 is claimed, TMPRs, containment, human-machine interface, payload, automatic protection of the flight envelope, and qualification for adverse environmental conditions.

The technical part mirrors the objectives: a row in Part T for containment answers Step #8, one for the flight envelope protection answers OSO #18, one for adverse conditions answers OSO #24. That is why a manual built to the Annex A structure produces the compliance matrix almost by itself, and why a manual written before the SORA has to be rewritten after it.

Seven steps from a concept of operations to an application

1. Write the concept of operations first, to the Annex A structure. Step #1 asks the operator to compile the operational, technical and organisational information: maps and diagrams of the operational volume, the ground risk buffers, the adjacent ground area and the adjacent airspace; the intended flight profiles, states and modes for the nominal, contingency and emergency phases; the mitigations to be claimed; and a description of the contingency volume and ground risk buffers with how they were determined. Chapter A.3 of Annex A gives the operations manual structure that carries most of this, so write to that structure from the start rather than converting a free-form document later.
2. Determine the intrinsic ground risk and the initial air risk from designated data. Step #2 sets the intrinsic ground risk class from the maximum characteristic dimension and maximum speed of the unmanned aircraft and the population density at risk in the operational volume and ground risk buffer, using the population density maps the competent authority designates; alternative data may be offered only if it is accepted. Step #4 sets the initial air risk class from the airspace: whether it is atypical or segregated, the altitude, controlled or uncontrolled, airport or non-airport, urban or rural. Where the operation crosses environments, the AMC says to repeat Steps #4 and #5 for each.
3. Decide which mitigations to claim, and at which robustness. Step #3, which is optional, lowers the ground risk class with the mitigations in Annex B: M1(A) sheltering, M1(B) and M1(C) operational restrictions, and M2 for the effects of ground impact. Step #5, also optional, lowers the air risk class with strategic mitigations from Annex C, operational restrictions the operator controls or airspace structure the authorities control. Every claim carries a robustness level, low, medium or high, and each level has an integrity and an assurance criterion the operator will have to evidence. A final ground risk class above 7 is outside the SORA and belongs in the certified category.
4. Derive the SAIL, the tactical mitigation, the containment and the operational safety objectives. Step #6 sets the tactical mitigation performance requirements for the residual air risk class, addressing detect, decide, command, execute and the feedback loop under Annex D. Step #7 assigns the SAIL, I to VI, from the final ground risk class and the residual air risk class. Step #8 sets the containment requirement, low, medium or high, from the unmanned aircraft characteristics, the SAIL, the average population density of the adjacent ground area and any outdoor assembly of people within 1 km of the operational volume. Step #9 identifies the seventeen operational safety objectives and the robustness the SAIL requires for each, from Annex E.
5. Build the initial compliance matrix and close Phase 1 with the authority. Phase 1 runs from Step #1 to Step #9 and should produce a document suite that describes the operation with the safety claims and derived requirements, together with explanations, not yet the full justification, of how each claim will be shown. The AMC says this may take the form of an initial compliance matrix in the shape of Annex A chapter A.4, and recommends contacting the competent authority early to reach an in-principle agreement on the final ground risk class, the residual air risk class and the SAIL before Phase 2 begins.
6. Draft the operations manual and the evidence for each objective. Point UAS.SPEC.030(3)(e) requires an operations manual when the risk and complexity of the operation require one, and point UAS.SPEC.050 requires the operator to establish procedures and limitations adapted to the operation and to ensure that remote pilots and other essential personnel have been informed of the manual. Annex A chapter A.3 lays it out in six parts: general, procedures, flight areas, training, the emergency response plan, and the technical part for each unmanned aircraft type. Each operational safety objective, each mitigation and each containment requirement then gets its evidence at the required robustness, and for low-robustness items a statement in the portfolio is mostly sufficient.
7. Assemble the comprehensive safety portfolio and apply. Step #10 compiles the portfolio: the finalised operational description, all safety claims with their robustness, all derived requirements, the compliance evidence, the linkages between documents, and a finalised compliance matrix that maps claims and requirements to evidence by reference. Every document is under version and configuration control, and external services are covered by references to their service level agreements. The application under point UAS.SPEC.030(3) then carries the operator's registration number, the accountable manager, the risk assessment, the list of mitigations, the operations manual and the insurance confirmation, on EASA Form 208, and the competent authority issues or refuses the operational authorisation.

What AI can draft and what the operator decides

A SORA is a chain of derivations from controlled inputs: the AMC and its annexes, the designated population and airspace data, the aircraft's characteristics and the operator's procedures. Each step looks up a table or applies a rule the AMC states. A language model working only from those documents, and citing the step, the annex and the input behind every value, can draft the whole chain and keep it consistent when one input changes. The claims, and the decision to fly, are the operator's.

The conditions that make this safe are the ones in Can AI be trusted for aviation compliance documentation?: a corpus limited to the AMC and annexes at the current edition, the designated data and the operator's own controlled documents; a citation on every value and every paragraph; a boundary on who may change the corpus; and a review record that shows who accepted each claim.

Five mistakes that produce a refusal

• Using the SORA as a checklist. The AMC says it is a guide to identifying and reducing risk, not a checklist. A portfolio that ticks objectives without tailoring the mitigations to the operation reads as one.
• A mitigation claimed in the SORA that the manual does not carry. A parachute claimed as M2 needs a procedure in Part B and a technical entry in Part T; a night restriction claimed as M1 needs to appear in the limitations. The authority reads the manual against the claims.
• Robustness claimed without the assurance. Each level has an integrity and an assurance criterion. Medium robustness with only a self-declaration is low robustness.
• Evidence pasted into the compliance matrix. Annex A chapter A.4 asks for the reference to where the evidence is found. The matrix is a map, and the evidence stays in the documents under version control.
• An operations manual from a template that describes another operator. Point UAS.SPEC.050 requires procedures adapted to the operation, and UAS.SPEC.030(2) requires a new application when the operation or its mitigations change significantly. A generic manual fails the first and hides the second.

How Wingman360 Teammate applies this

The SORA workflow in Wingman360 Teammate starts from the AMC and its annexes at the current edition, the designated population and airspace data the operator holds, the aircraft documentation and the operator's existing procedures that its administrators have ingested. It drafts the concept of operations to the Annex A structure, proposes each risk class with its inputs cited, lists the objectives and their robustness for the SAIL, drafts the operations manual part by part with the objective each section answers, and builds the compliance matrix, reporting every requirement without a reference and every claim without a procedure. The operator decides the claims and the robustness, approves the manual, and the accountable manager signs the application. The same approved knowledge base answers questions from the manual and the AMC during operations, and when the operation changes it re-derives the affected steps. Each deployment is a dedicated single-tenant instance in the operator's own cloud or on-premise, with a local model option. What else it drafts for a UAS operator, including the LUC manual, is on the UAS manufacturers and operators page.