User manual

Operations

Everything you decide before flying lives in the Operations cluster: missions, operation orders, quick dispatch and UAS zones. The mission is the dossier that holds weather, crew, checklists, flights, live streaming and deliveries together.

Creating a mission

In the form you set a Title, a Sector (Inspections, Agriculture, Photo/video, Mapping / LiDAR, Public safety / SAR, Training, Other), a Status and the Flight window, whose end must come after its start. Client and Operation Order are optional. Address, latitude and longitude feed the weather and the map: without coordinates the weather traffic light cannot be computed.

The mission gets a progressive code per organization — MSN-0001, MSN-0002 and so on. The status is a plain selector — Planned, Active, Completed, Cancelled — that you update yourself: there are no automatic transitions.

At the bottom sits the Risk assessment section, collapsed by default, with four free-text fields: operational scenario, ground risk, air risk and mitigations. That is where you jot down the reasoning that the SORA later formalizes.

PIC and SPIC right in the form

PIC (pilot in command) and SPIC (second pilot) are now chosen in the mission form itself, without going through the Crew tab. Both fields are optional: you can save a mission and assign the pilots afterwards.

One thing to keep in mind: these two fields set the PIC and the SPIC of Crew 1. Any further crews have their own, and you manage them from the Crew tab.

Two rules always hold. First: the PIC and the SPIC must be two different people, because nobody commands and backs up the same flight. Second: whoever holds a flying role — PIC, SPIC or Pilot — must have a certificate valid on the mission's end date, recorded in this same organization.

It is worth knowing how the check works, so you do not misread it: the dropdown lists all members of the organization, expired certificates included, and the refusal comes on save, not by filtering the options. If the end date is not filled in yet the check does not run, because there is nothing to compare against. When you change who holds a role, the previous holder leaves the crew; the other rows are untouched, and anyone already in the crew under a different role keeps it.

Crews, roles and guests

The Crew tab is where the team really takes shape. Each row is a person with a role, and the rows are grouped into numbered crews: a mission can field more than one — two teams on two take-off points, shifts relieving each other — and the PIC and the SPIC are unique per crew, not per mission. With two crews there are legitimately two PICs.

The Add person button inserts a row into the crew you choose; Add crew opens the next one straight away, already set to the PIC role, because as a rule a new crew starts from its pilot in command. The table is grouped by Crew 1, Crew 2 and so on, so you can see at a glance who is with whom.

There are nine roles available:

• PIC (pilot in command), SPIC (second pilot) and Pilot — these are the flying roles: they handle the aircraft and require a certificate valid on the mission date.
• Observer and GCS operator — eyes on the aircraft and the ground control station; no certificate required.
• Assistant, Technician and Driver — the supporting cast a real operation brings along: whoever holds the perimeter, whoever fits the payload, whoever drives the vehicle.
• Trainee (under training) — flies dual-control under the PIC's responsibility. Precisely because they are under training, no certificate is asked of them: if they genuinely handle the aircraft on their own, the right role is Pilot, with the check that comes with it.

One person can hold several roles on the same mission; what the system refuses is the same person with the same role in the same crew, which is a duplicate and nothing more.

External guests without an account

In the field you often have someone alongside you who is not in the organization: the observer from the command, the client's technician, the driver of the vehicle. Creating an account for them for a single day makes no sense, and leaving them out of the crew record makes no sense either.

That is why each crew row has the External guest (no account) switch. Turn it on and, instead of the Person, you enter their Full name and — optional but useful — the Body or company they come from. In reports and lists they appear as "John Smith (Fire & Rescue Service)", which is exactly what you need to read after the fact.

Each row is either a member or a guest, never both and never neither: switching mode clears the previous identity, so no half-filled data is left lying around.

The limit here is clear-cut and deliberate: an external guest cannot hold a flying role. With the switch on, the role menu shows only the seven non-flying roles — GCS operator included — and PIC, SPIC and Pilot are simply not there. The reason is documentary honesty: the platform holds no record of a guest's certificates, so no certificate check is run on them and there is no pretending one was verified. Whoever handles the aircraft has an account in the organization and a certificate recorded here, full stop.

Operation orders

Structured organizations protocol their Operation Orders. Each ODO gets a protocol number, ODO-2026-001 (year plus a three-digit sequence, per organization), and carries a category — from Open A1/A2/A3 through Specific STS-01/STS-02/PDRA to Operational authorization and Certified — a scenario, an operational authorisation number, a location, a validity window and Limitations and prescriptions.

Creating, authorizing, closing and revoking an ODO is reserved to Owners and Admins; other members can read it. The Authorize action is only available from draft, and it records who authorizes and when: it is a signature in the traceability sense, not a graphic or digital signature. From that moment the ODO can no longer be edited or deleted, and only Close and Revoke remain, both tracked in its status.

Missions attach to an ODO from their own form. When you record a flight on an attached mission, the logbook entry inherits the ODO and takes the progressive TO number under that protocol: the reference you read is ODO-2026-001 / TO-3. The sequence runs per order, not per mission, and is assigned when the logbook entry is created.

Quick dispatch

For rescue work and recurring operations you prepare mission templates: name, sector, address and coordinates, expected duration (from 10 to 480 minutes, 60 by default), plus the checklist template, the drone and the primary live channel to carry along.

The Activate now button immediately creates a mission that is already active, with a window running from now for the expected duration, the drone attached, the live channel linked and the weather refreshed if the network allows. Whoever activates it joins the crew as a pilot if they hold a certificate valid today, otherwise as an observer — never as PIC or SPIC, which stay a deliberate choice. Client, ODO, equipment and the rest of the crew are not copied: you add those once the mission is open.

ED-269 geographical zones

From the UAS zones page you upload your country's geographical-zones file. The format is the European standard ED-269 in JSON, and its GeoJSON serialization (ED-318, the one published by Estonia and Ireland) is accepted too. The file can be up to 50 MB.

The page tells you where to download it: fourteen countries are mapped, and the portal you are pointed at is your organization's — d-flight for Italy, DIPUL for Germany, Géoportail for France, ENAIRE for Spain, GoDrone for the Netherlands, and so on. Only in Italy does the download require an operator account on the portal.

Two things to know. An organization has a single active zones file: every upload replaces the previous one. And after 14 days the page warns you that the file is stale and worth downloading again.

The UAS zones page holds no map: it shows the file's status, the national source and the upload. The zones are shown on the mission map, colored by restriction — red for prohibited zones, orange where authorization is required, yellow for conditional ones, blue for the rest — with altitude limits and the zone's message in the popup. The same zones also appear under the flight track in the replay.

Checklists

Checklists are organized into four phases: Pre-flight, Pre-takeoff, In-flight and Post-flight. When you register the organization you already find four ready-made templates, one per phase. The items of an individual checklist can be edited freely; the starting templates, on the other hand, have no management page today.

In pre-flight and pre-takeoff checklists the system inserts the automatic checks at the top, already ticked if they pass and already failed if they do not:

• crew certificates valid at the mission's end, for flying roles only — trainees and external guests stay outside the check;
• ODO authorized and valid, covering the whole window — the item only appears if the organization uses operation orders;
• the weather light: red fails, yellow passes with a note, and if the weather has not been fetched yet the item comes up ticked (there is no data to fail on);
• at least one drone assigned to the mission;
• drone insurance not expired (an untracked policy does not fail the check);
• at least one charged battery for every drone on the mission;
• remote controller paired and charged for every drone — the item only appears if you inventory your remote controllers;
• payload calibrations for the payloads fitted to the mission's drones.

A checklist can only be signed when complete: if even one item is unticked, the signature is refused. Once signed it records who and when, and it can no longer be edited or deleted.

Signing the post-flight sets the consequences in motion: the charged batteries of the mission's drones move to "To charge", and so does any equipment with an internal battery taken into the field. The dialog also asks whether there was an anomaly: choosing maintenance opens an inspection on the drone, choosing incident opens an incident linked to the mission. Completed checklists and blank templates can both be printed to PDF.

SORA

The SORA assessment action on a mission opens a single dialog that applies the SORA 2.0 methodology (JARUS/EASA, Specific category): you pick the operational scenario, the aircraft's characteristic dimension — prefilled from the mission's largest drone — the robustness of the M1, M2 and M3 mitigations, and the initial and residual ARC.

The engine computes iGRC → final GRC → SAIL → required robustness of the 24 OSOs, saves the outcome into the mission's risk assessment and lets you download the PDF. Watch out for one case: if the final GRC exceeds 7 the operation is outside the Specific category, so no SAIL is computed and no OSO is listed.

The document says so explicitly: it is a decision-support aid, not a formal SORA and not a declaration to the authority. The values must be verified, completed and signed off by you, in line with your national competent authority.

Weather

Over the flight window the mission shows a traffic light computed on the window's maxima, and the worst condition always wins: red at 40 km/h of wind, 55 km/h of gusts or a 60% chance of precipitation; yellow from 25 km/h of wind, 35 km/h of gusts or 30% precipitation; green below all three.

Next to the light you get the hour-by-hour detail: wind including at 120 meters, cloud cover and cloud base, visibility, temperature and dew point, sunrise and sunset with the golden hour, and the geomagnetic Kp index from NOAA (from Kp 5 it is a storm). Where there is a station nearby, raw METAR and TAF are added along with the VFR/MVFR/IFR/LIFR flight category.

The data comes from open-meteo, which is free and redistributable: that is why the snapshot can be saved and printed into PDFs. If the organization configures a Windy key, the data comes from there instead, falling back automatically to open-meteo if anything goes wrong. The weather is refreshed with the Refresh weather button on the mission; the weather report PDF, on the other hand, is attached from Quotes and Invoices, as evidence of the window you chose.