Writing a Drone CONOPS and Operations Manual: A Practical Irish Evidence Template

Give the operating concept a clear boundary

A concept of operations, often called a CONOPS, explains the proposed activity in a way that the crew, customer and authority can understand. It is the starting description, not the complete risk assessment or authorisation. State what is transported or applied, where the aircraft operates, who controls it and why that method is needed. EASA’s Specific-category guidance explains how an operations manual supports the applicable authorisation pathway.

For an illustrative FlyCart project, a useful opening is: “move specified sealed components between a controlled loading site and a controlled receiving site on the identified route, using the stated aircraft configuration and crew”. The details still need to be supplied and demonstrated. “Provide deliveries anywhere in Ireland” is too broad to assess without a defined method for approving each location. A good scope also states exclusions: unassessed cargo, unsupported aircraft configurations and operations beyond the accepted visibility or environmental limits must not drift into the job informally.

Use a concise mission data sheet

Create a first-page data sheet that can be checked against the rest of the application. Suggested fields include operator identity, task, aircraft and software configuration, maximum operational mass, payload arrangement, proposed flight mode, visibility basis, operating locations, height reference, crew roles, environmental limits and permission dependencies. Identify whether each entry is a confirmed fact, a proposed limit or an action awaiting evidence. This distinction prevents a planning assumption becoming an apparent approval.

Use document references rather than copying a manual’s whole specification table. For example, link the payload configuration to the relevant manufacturer document and the load schedule to a controlled appendix. The current EU rules are the governing reference for the chosen pathway. If an application uses SORA, select the version consistently. IAA UAM 012, Issue 6 currently explains the coexistence of SORA 2.5 and SORA 2.0; a 2.5 heading over copied 2.0 tables is not a coherent assessment.

Make the maps carry operational information

A location plan needs more than an aerial photograph and a take-off pin. Show normal flight geography, relevant contingency space, the ground risk buffer where applicable, take-off and receiving areas, pilot and observer positions, access control and neighbouring features that influence risk. State the coordinate system, height reference and date. The IAA spatial-planning guidance gives useful definitions; the applicable assessment determines the dimensions and evidence needed.

Connect map labels to procedures. If area R1 is the receiving site, the briefing, communication call and emergency plan should use the same identifier. If a public track is a constraint, show its position and document the actual lawful control or route arrangement; do not simply colour it green. For multiple sites, define a site-acceptance process and its limits rather than inserting an undefined promise that all locations will be inspected. The file should make it possible to reject a site that does not fit the operating concept.

Write procedures that allocate actions

Organise procedures by phase: task acceptance, planning, setup, pre-flight, launch, transit, application or delivery, return, shutdown and post-flight review. For each critical action, identify who performs it, what they check, what evidence is retained and what happens if the check fails. “Ensure the area is safe” is weak unless the manual explains which area, who has verified it and how the pilot is told.

Use checklists for repeatable decisions while keeping the reasoning in the supporting procedure. A cargo task might require an identified load, attachment inspection, mass confirmation, clear receiving area and explicit launch clearance. An agricultural task needs material and application checks appropriate to its lawful purpose. These are proposed headings, not a universal approved checklist. Check the actual FlyCart manual or applicable Agras manual before specifying assembly, inspection or emergency actions. Never invent a load-release or flight-termination instruction to complete a template.

Create an evidence register with owners

The assessment makes claims; the evidence register shows why the operator is entitled to make them. Suggested columns are requirement, operational claim, supporting document, revision, responsible person, verification method and outstanding action. Examples include a crew competence record, aircraft limitation, maintenance procedure, communication test or technical assurance report. Link the exact item that supports a claim rather than attaching an undifferentiated folder of brochures.

Do not mark every row compliant before the supporting work is done. A manufacturer’s marketing page may establish a feature exists, but not the level of assurance required for a particular safety objective. A supplier’s explanation may help identify the right documentation without replacing it. Where the evidence is missing, decide whether to obtain it, change the operation or remove the unsupported claim. This discipline makes the application more reviewable and helps the business understand which apparently attractive jobs require a different technical or operational approach.

A useful close-out review asks whether each claimed mitigation has an owner who can implement it during a real job. If the answer relies on somebody not identified in the crew plan, repair that organisational gap before presenting the mitigation as established.

Integrate people, emergencies and task permissions

The manual should connect competence, operational control and emergency response rather than treating them as isolated appendices. Define who accepts a task, who releases an aircraft after maintenance, who briefs the crew and who can stop operations. Include the emergency plan or a controlled reference to it. The Irish application guidance lists the operations manual, emergency arrangements, insurance and supporting evidence; a SORA package needs the assessment and referenced documents as applicable.

For pesticide proposals, document the separate DAFM permission workstream and keep unresolved items visible. For a construction-site lift, identify the interface with the site’s risk assessment and access arrangements. The HSA risk-assessment guidance concerns workplace obligations that remain alongside aviation compliance. A useful manual tells staff which authority or manager owns each permission and what must be verified before a job proceeds. It should never imply that an accepted aviation document grants access to every site or authorises every material.

Control revisions and perform a consistency check

Give the manual a version, date, document owner and change history. Keep a controlled copy available to those who need it. Before submission, compare the application form, CONOPS, maps, risk assessment, aircraft list, training records and insurance description. They should describe the same operation. Check that load masses, visibility assumptions, aircraft configurations and limits agree. A small inconsistency can reveal a more important mismatch in how the job has been designed.

An illustrative review asks another competent reader to plan one mission using only the file. Note every place they must guess, then repair the ambiguity. Check external-source revisions and internal cross-references as well. For an Irish application, follow the current IAA submission process; do not assume a document upload constitutes permission. Irish Drone can help organise the equipment information and SORA preparation around an actual Agras or FlyCart project. Start with a defined mission and a site map so the resulting manual is useful to the crew as well as reviewable by the authority.

Frequently asked questions