User manual

Compliance

The Compliance cluster gathers what you need in order to show how you work: the Expiry board, the Incidents register with the dossier you hand over, the Operations Manual with its revisions, and the SOS alerts that come in from the field.

The expiry board

Every deadline flows into a single page. There are nine sources: drone insurance, payload calibrations, maintenance with a next due date, recurring maintenance schedules (by hours, cycles or calendar), pilot certificates, end-of-life batteries, batteries left charged for more than ten days, battery health that is not good, and equipment calibrations.

The page looks ninety days ahead and every entry falls into one of three bands: Expired in red, Due soon in amber when less than a month is left, OK in green beyond that. Signals that carry no date — an end-of-life battery, for example — land in "Due soon", because they are things to look at now.

At the top of the page, when there are any, you find the battery alerts not yet acknowledged, criticals first.

Every morning at 7:00 a digest goes out with the deadlines of the following seven days. It is worth being precise about how it arrives: it is a notification in the bell and, for anyone who has enabled browser notifications, a push as well. It is not an email. Owners and Admins receive it, and only if there really is something expired or expiring — no notification just to say everything is fine.

Incidents

When something happens, you open an incident. The form is split into four blocks: what happened (date and time, type from twelve categories, severity among Near miss, Minor, Major and Accident, status, a mandatory description and immediate actions); the assets involved (mission, flight, drone, pilot, place, coordinates); the consequences (damage, injuries, third parties involved with details); and the authority block.

About that last one, it is worth saying exactly what it does and what it does not do. There is a "Reportable to the authority" switch, which comes up already on for the types that normally are — airprox, collision, injury, fly-away — and a field for the case reference. The platform states it itself: this is guidance, not an automatic filing. Nothing is sent to ENAC or to any other authority: the register is internal and the formal report is made by you, through the channels that apply to you.

The status follows the work along: Open, Investigating, Reported, Closed. Evidence is uploaded as files (up to around 500 MB each) and each one keeps its original name and its SHA-256 fingerprint.

An incident can be opened from three different places, and it is worth using the one closest to the event. From the Incidents list, when you are recording it after the fact. From a flight's page, with the Report incident action: the incident is created already linked to the flight and prefilled with the post-flight analysis findings — altitude over the limit, critical battery, questionable distance. And from signing the post-flight, choosing incident as the anomaly: it is created linked to the mission and the drone, as a technical failure of minor severity, ready to be completed.

Owners, Admins and Pilots can open and edit incidents; everyone else can read them. The menu entry carries a counter of incidents not yet closed.

The incident dossier

The Download dossier (ZIP) action assembles, in one go, the package to hand to an insurer or an authority. Inside you find the dossier PDF, the telemetry as JSON if the linked flight has any, and the evidence folder with the original files.

The PDF lays out, in order: the header with the operator and operator code; the summary of the occurrence; the consequences; the flight's logbook entry with duration, drone, pilot, anomalies and its hash-chain fingerprint; the aircraft's identity with class, MTOM, insurance and firmware; the pilot, with a note on whether they held a certificate valid at the time of the occurrence — not today, at the time of the occurrence; the mission with its weather light, maximum wind and the signed checklists with signatory and time; the telemetry statistics; the list of evidence with file sizes; and finally the authority block.

At the end, the document explains where the guarantee lies: the logbook entry is chained with SHA-256 and every piece of evidence carries its own fingerprint.

Operations manual

The Operations Manual is the file that describes how your organization operates, assembled and versioned by the platform. You pick a module from the seven available — surface cleaning (facades), agriculture, surveillance, infrastructure inspection, search and rescue, aerial filming, delivery — the jurisdiction among those that module covers, the name of the Accountable Manager, and the declared mitigations and payloads.

The document is made up of ten sections, from general information through scope and risk basis, organization and crew, fleet, operational procedures, the regulatory layer, emergencies and response plan, records, the master document list and the revision log. The operational content is taken from your real data: drones in the fleet, crew with their certificate status, authorized operation orders.

The master document list brings together pilot certificates, drone insurance and authorized operation orders, each with its status — expired, expiring within thirty days, valid.

The lifecycle is simple. The manual starts as a Draft, with an OM-001 code that is progressive per organization, edition 1 and revision 0. Owners and Admins can approve it: from that moment it is approved, it records who approved it and when, and a row is added to the revision log with the edition, the revision and a snapshot of what was declared. An approved manual can no longer be edited or deleted — not even by going in through the direct address — and to work on it again you have to open a new revision, which increments the number and takes the document back to draft. The revision log is read, not written.

The PDF can be downloaded in any state, drafts included.

Two limits to state. The first is stated by the code itself: the platform does not certify compliance, it assembles and versions the file. The second concerns the regulatory layer: the per-country cells are an AI-assisted first draft, to be validated, and where a cell has not yet been verified the document flags it as a gap instead of inventing content. The manual also highlights incompatibilities: a payload that is not operable or is prohibited in that jurisdiction is put front and center.

SOS from the field

The SOS is the red button at the top of the field app's home screen. It takes two taps — you press, you confirm, optionally with a message — and it is not a long or complicated gesture, because with gloves on or in the rain, gestures fail.

The position goes out with the request, if the device grants it within ten seconds. If GPS is denied or does not answer, the SOS goes out anyway, without coordinates, and the app tells you so plainly: better an alert with no position than no alert.

There are other ways in as well: an SMS from a registered number, and the satellite communicators — the inReach and SPOT feeds are polled every ten minutes and a point flagged SOS triggers the alert, while Iridium terminals arrive by webhook.

The alert reaches Owners and Admins — the "ops room" — in the bell, by push and, for anyone with a registered phone number, by SMS with a link to the map. If the same operator triggers it again within a quarter of an hour, the open alert is updated with the new position instead of a second one being created.

The workflow has four states: Triggered, Acknowledged (recording who and when), then Resolved or False alarm. Alerts cannot be created from the panel: they only come from the field.

One point has to be repeated because it is the one that counts: the SOS does not replace 112 or the emergency services, and it is not a certified Cospas-Sarsat beacon. It is the sending of a position and a request for help to the people responsible in your organization. If there is a real emergency, you call 112.