SORA 2.5 Application Review: Evidence Gaps, SAIL and Manual Consistency

Preparing a SORA-based operational authorisation package is not just filling in one form. It is a document-control problem: the official EASA material, the application draft, CONOPS, operations manual, UAS evidence, risk tables, compliance matrices, mitigation records, pilot records, and national-authority notes all need to stay consistent.

The useful task is narrower than producing an entire safety assessment: connect a claimed mitigation to the exact supporting document, identify an inconsistency or missing fact, and draft a question or correction for the responsible reviewer.

Availability, October 2026: The current Aviation.Bot legacy beta supports EASA source research and chat. V2's combined organisational-document and regulatory-library workflow is in development. Private application review and task-specific SORA skills described here are planned, not capabilities available in the current beta.

This article includes a historical recorded demonstration with fictional operator files: NorthSea Aero Logistics, a commercial drone operator preparing a specific-category application package for BVLOS infrastructure work in the Netherlands. It is not an approved application or customer result.

The May 2026 demo used public EASA and Dutch ILT source material, synthetic company files, and an agent run that generated a pre-submission gap review. This prototype demonstration does not establish current library coverage, a publicly available workflow or measured accuracy for a real submission.

This is preparation support, not regulatory advice. A qualified compliance lead and the relevant competent-authority process remain required before any real submission.

EASA, UK CAA And FAA: Choose The Correct Route First

These are different frameworks, not interchangeable source folders. Record the jurisdiction, actual operation, approval route and source edition before reviewing an application. BVLOS is a description of an operation, not permission to conduct it.

EU: SORA 2.5 And The Competent Authority

EASA's June 2026 Unmanned Aircraft Systems rules include SORA 2.5 in AMC1 to Article 11. It supports risk assessment for a specific-category operational-authorisation application; the relevant competent authority assesses that application. EASA publishing the methodology does not mean an operator submits every application to EASA.

Check the route first: a standard scenario, applicable predefined risk assessment or another permitted route may change the material required. This article does not decide which route your operation qualifies for. National application requirements and the chosen operation still matter.

SAIL means Specific Assurance and Integrity Level, with levels I to VI. In the SORA methodology it relates the assessed risks to the assurance and evidence needed. It is not a separate approval, and selecting a level does not establish that the operation is safe. Separate the operator's procedures and competence evidence from manufacturer design/test evidence; the latter cannot be created by a language model. Check the applicable technical requirements and conditions rather than treating every SAIL as the same certificate requirement.

UK: UK SORA, Application Phases And SAIL Mark

Use the UK CAA's UK SORA application process and its current guidance, not an assumed copy of the EU route. Keep the phase-specific authority decisions and requested evidence separate from the final operational-authorisation decision.

The CAA's phase guidance distinguishes Phase 1, which assesses SAIL, from Phase 2, which assesses compliance evidence, including OSOs and containment. A Phase 1 result is not the final permission to operate.

A UK SAIL Mark certificate concerns specified UAS technical requirements. It is not an operator's permission to fly. A document-review task can identify which technical evidence was supplied and where a claim lacks support; it cannot certify the design or replace the CAA's assessment.

US: FAA Waivers Are Not A SORA Application

For an operation within Part 107, start with the FAA waiver guidance. An operational waiver and an airspace authorisation are distinct; do not label either a SAIL approval or assume that Part 107 covers every proposed UAS operation.

The current FAA waiver page asks applicants to explain operational hazards and mitigations and identify relevant supporting material. It directs new operational-waiver applications to Aviation Safety Hub; airspace authorisations use a separate process, including LAANC or DroneZone as applicable. Check the current official instructions before submitting. A useful document review checks whether each claim has evidence and consistent manual references. It does not establish an equivalent level of safety, guarantee a waiver or turn a proposed regulatory change into effective permission.

The Netherlands example below illustrates an EU document-review method. It is not a UK application template or an FAA waiver package.

Why This Becomes A Workspace Problem

A SORA package has many moving parts:

• the current SORA methodology and related AMC/GM material
• the operational authorisation application form and current draft
• the operator's concept of operations
• UAS system, C2 link, containment, maintenance, and emergency-response evidence
• risk registers and mitigation evidence matrices
• remote pilot competence records
• operations manual sections that must match the application
• national or local authority constraints for the state of operation

The hard part is consistency. A single mismatch such as altitude, operating area, mitigation owner, evidence ID, or document revision can create review work later.

In the recorded demo, the generated gap review found exactly that kind of issue: the application draft used one altitude assumption, while the CONOPS and operational-volume evidence used another.

What Goes Into The Workspace

For a real review, keep an inspectable source manifest: canonical URL, authority, edition, access date, material status and applicable dates where established. File size and checksum can identify downloaded evidence. In the historical demo pipeline the manifest was a sidecar artifact; that organisation of files is not a requirement for every operator. The reviewer must still be able to inspect it.

Useful EASA starting points include:

• EASA SORA overview
• ED Decision 2025/018/R, including the SORA 2.5 annex, explanatory note, and corrigendum
• Easy Access Rules for Unmanned Aircraft Systems
• Specific-category application forms
• EASA operations manual example for SAIL II UAS operations
• Critical Area Assessment Tool guidance

Because the fictional operator is based in the Netherlands, the demo also includes Dutch ILT pages captured as PDFs. Those historical captures are not evidence of current ILT requirements. Check current national application instructions before using any real package; do not substitute UK or FAA material for the applicable EU/national route.

Company Files To Add

After the official sources, add the operator files. A useful SORA review workspace normally includes:

• current application form draft
• CONOPS or equivalent operation description
• UAS system description
• draft operations manual
• operational volume and ground risk buffer evidence
• risk register
• compliance matrix
• mitigation evidence matrix
• remote pilot competence matrix
• maintenance, C2 link, containment, and emergency-response procedures
• national or local-condition evidence where applicable

The demo uses synthetic DOCX, XLSX, and PDF files instead of Markdown because real SORA work normally happens across office documents and formal PDFs.

Worked Example: A Claim Without Matching Evidence

The following is an illustrative fictional record, not a new finding from the recorded run. The identifiers and observations are invented to show the review method, not acceptable technical evidence or a regulatory decision.

Review item	Fictional record
Route and source	EU specific-category application; exact SORA edition and national application instructions must be confirmed.
Claimed mitigation	The application points to containment evidence CE-07.
Supporting document	The supplied index points to report CE-04; no CE-07 report is included in the selected files.
What can be concluded	The selected package does not provide an unambiguous link from the claim to supporting evidence.
What cannot be concluded	That no report exists elsewhere, that containment has failed, or that the operation meets the required assurance.
Draft action	Ask the owner to identify the correct report, version and relevant passage; reconcile the references before review.
Human decision	Open; no risk acceptance, design validation or authorisation implied.

A bounded draft note would be:

The application references CE-07, while the supplied evidence index references CE-04. Confirm the intended report and version, provide the relevant supporting passage, and explain whether the two references describe the same evidence. Technical adequacy remains for the qualified reviewer to assess.

This is the information gap a document assistant can help expose. Writing persuasive text cannot replace missing test results or justify an unsupported mitigation.

A Review-And-Draft Prompt For V2

For the planned workflow, supply a named source/document set. Ask for a proposed review artifact, not an application approval. The historical demonstration is one example, not a validation of the prompt below on real submissions.

Review this selected application package for the stated jurisdiction and
approval route. Confirm the official source editions and list missing inputs.
Compare the application, operation description, manuals and supplied evidence.
Return claim -> exact source/document passage -> inconsistency or evidence
request -> draft clarification -> human-review status. Keep EU SORA, UK SORA
and FAA waiver requirements separate. Do not invent hazards, test evidence,
risk acceptance or an approved assurance level. If a cited source or record
cannot be inspected, leave the item unresolved. Do not edit controlled files
or submit anything to an authority.

The exact wording can change. The important pattern is:

1. name the official sources and company files in scope
2. ask for missing evidence and inconsistencies
3. ask for a concrete review artifact
4. keep the output bounded as preparation support

What The Agent Did In The Demo

The recorded run used a real model, not a scripted final answer. During the run, Aviation.Bot indexed the workspace, opened the application draft, inspected the official source PDFs, read the SORA annex and Form 208 material, checked the Dutch ILT captures, inspected Word documents and spreadsheets, searched for missing evidence files, and then wrote the gap review.

The final output is a pre-submission gap review. It is not an approval opinion. It gives the operator a practical list of items to review with a compliance owner.

The report flagged issues such as:

• inconsistent altitude and operational-volume assumptions
• missing KML/KMZ or equivalent location package evidence
• missing adjacent-area population-density support
• containment evidence ID mismatch and missing flight-test evidence
• incomplete emergency-response revision and role alignment
• operations manual maturity gaps
• weak compliance-matrix traceability
• missing insurance evidence for the ILT application context

What A Single Uploaded PDF Cannot Establish

Reading one PDF can help explain it, but cannot establish consistency with evidence that was never supplied. Conversely, indexing a folder does not establish exhaustive retrieval, correct applicability or evidence adequacy. The quality of a review depends on the selected sources, actual records and human checks, not the number of files alone.

For a SORA package, the useful workflow is:

1. keep official sources and operator evidence in one folder
2. index PDFs, Word files, spreadsheets, and notes together
3. let the agent search and inspect the original source files
4. create a reviewable output in the same workspace
5. let a human owner verify each finding against the cited documents

This is the intended V2 review loop, not a current legacy-beta capability. It should leave source documents inspectable and produce a draft record that can be reviewed using the operator's established process. Any time saved or advantage over another tool needs measurement on real reviewed tasks.

How To Build This Workspace Yourself

1. Create a controlled folder for the application package. If you already have access to a suitable document-workspace tool, use it only under your organisation's data-handling rules; this article is not an instruction to install a new Aviation.Bot app that has not launched.
2. Download the relevant official EASA sources listed above and store them under a sources/easa/ folder.
3. Add national or local authority material under a folder such as sources/naa/ when your operation depends on state-specific conditions.
4. Add your own operator files under folders such as company/, risk/, and evidence/.
5. Include the application draft, CONOPS, operations manual, risk register, compliance matrix, mitigation evidence, pilot competence records, UAS system description, and emergency-response material.
6. Review the selected files manually or with an authorised document tool available to you. Aviation.Bot V2 is intended to support this comparison when released; the current legacy beta cannot be assumed to deliver the joined workflow.
7. Inspect every cited source and assign a human owner for each open action.

Do not stop at an AI output. Treat it as a proposed worklist; verify each cited passage and distinguish a missing input from an established deficiency. Do not use the draft to attest technical performance or close an authority request.

What To Avoid

Do not ask any AI tool to approve a SORA application. Do not rely on a generated answer without checking source documents. Do not use a workspace like this as a substitute for national requirements, privacy and data-protection review, insurance, liability, security, environmental constraints, or competent-authority guidance.

The proposed scope is narrower: source research, cross-document consistency review and draft clarification text. It does not include engineering calculations, autonomous risk assessment, a complete safety case, authority submission or approval tracking.

How Aviation.Bot Can Help

Current legacy beta: Aviation.Bot provides supported EASA source research and chat. It does not yet offer the joined private-document/library review shown by the prototype. This article does not establish current UK CAA or FAA library coverage.

Planned V2: combine selected official sources with permitted application drafts, manuals and evidence to prepare cited review notes and draft questions. A browser user would upload permitted files; a desktop user could select local files. The planned external library would require online access. Do not infer local-only processing, GDPR compliance or equivalent model quality from a desktop interface; confirm the actual indexing, retrieval and model data paths against organisational policy.

What A Task-Specific Skill Should Enforce

An intended provider-authored skill could standardise the intake, source checks and output format. Organisation-defined instructions could add internal document naming and reviewer conventions. Neither replaces the source requirements or grants an approval. These SORA/waiver skills are concepts here, not released Aviation.Bot features.

The task contract should require:

• a separate EU SORA, UK SORA or FAA waiver profile, with authority, route and source edition;
• selected organisational documents and authorised evidence, with their versions;
• exact passage references, missing-input branches and distinction between claimed and demonstrated evidence;
• draft observations, clarification questions and proposed wording kept separate from accepted decisions;
• human verification before any controlled-document change, technical assertion or submission.

See the MOE review checklist, worked change-impact matrix and regulatory change-impact review for the same review-and-draft pattern in maintenance documentation.

Library status: The new external library and joined web/desktop workflow are under construction. Sign up on Aviation.Bot to stay up to date about upcoming releases.