Flight Operations needs to see, at a glance, who is current to fly what — and needs to know before something expires, not after. Pilots need to see their own status, log their own currency events, and get told when something is coming due. Auditors and customers need the evidence behind every green light. One system has to do all three, and it has to be easier to use than the spreadsheet it replaces.
What gets tracked
| Record type | Examples | Who creates it | What drives expiry |
|---|---|---|---|
| Qualifications | Platform initial (e.g., Heavy Lift), transition (Commander 3XL), mission-specific add-ons, instructor (QI), evaluator | Evaluator, on a signed grade sheet | Recurrent evaluation interval (proposed 12 months) |
| Currency items | Flight recency per platform (proposed: 3 flights in the preceding 90 days); Part 107 recurrent training every 24 calendar months (14 CFR 107.65); customer- or site-specific authorizations; any waiver-specific training a customer operation requires | Pilot (self-service) with instructor sign-off where required; the LMS automatically for training completions | Recency windows and calendar rules |
| Evidence | Signed grade sheets, LMS exam results, FAA completion certificates, flight logs, downgrade/requalification records | Attached at the point of entry | Retained for the life of the record; never edited, only superseded |
Three views of the same data
| User | What they see and do |
|---|---|
| Pilot | A single status page — green / amber / red — listing every qualification and currency item with its due date. Log a flight, upload a certificate, acknowledge an alert, from a phone. No hunting through a shared drive to find out whether you are legal to fly next Tuesday. |
| Instructor / Evaluator | Enter and sign grade sheets (the PQS task table, graded); issue, renew, suspend, or requalify a qualification; see their students’ progress and outstanding items. |
| Flight Operations | The matrix — every pilot × every qualification and currency item — filterable by platform, customer, and site; an “expiring in 30 days” list; an assignment check (“is this pilot current to fly this platform for this customer today?”); one-click evidence export for any pilot on any date; program-health metrics. |
Alerts that reach people
Every dated item has an alert schedule. Proposed: email and SMS to the pilot at 60, 30, 14, 7, and 0 days before expiry; email to the pilot’s supervisor at 30, 7, and 0; a daily digest to Flight Operations of everything expiring within 30 days and everything expired; automatic removal from the assignable roster on expiry; alerts suppressed the moment the item is renewed. Flight-recency items alert when the window is about to lapse, with the shortfall stated (“1 of 3 flights in 90 days”). The point is that nobody discovers a lapse by being asked for evidence.
Prototype
Interactive prototype — Flight Ops currency matrix. Sample pilots and dates; client-side only. Change the “as-of” date or log an event to see status and alerts recompute.
Rules in this prototype: each platform qualification renews on a 12-month recurrent evaluation; flight currency is tracked per platform (3 flights on that platform in the preceding 90 days); assignability is decided per platform — lapsing on one aircraft never bars a pilot from another they are current on; Part 107 recurrent training every 24 calendar months (14 CFR 107.65). Intervals other than the FAA rule are proposed, not policy. Alert schedule 60/30/14/7/0 days to the pilot, 30/7/0 to the supervisor.
How to build it — three honest options
| Option | What it is | Strengths | Trade-offs |
|---|---|---|---|
| 1. Existing drone-operations SaaS | DroneLogbook (pilot currency monitoring, personnel dashboards, document-expiration and low-currency notifications, skills/capabilities tracking, flight-log import, compliance reporting) or AirData (fleet, maintenance, and log synchronization). | Fastest path to mobile apps and automated flight-log import, so currency events populate themselves; compliance reports built in. | Currency rules must fit the vendor’s model; PQS task-level grading is unlikely to be native; compatibility with Draganfly’s Cube/DGCS flight logs must be verified before committing; per-seat cost; data lives with the vendor. |
| 2. Low-code build | Airtable or a comparable database with forms for pilot entry, filtered dashboard views, and an automation layer (Make/Zapier + Twilio) for email and SMS. | Stood up in days, cheap, shaped exactly to the qualification standard; a working matrix in the first 30 days. | Signatures and immutability are weaker than a purpose-built system (edit history, not signed records); someone has to own it; scaling and access control need discipline. |
| 3. Purpose-built module on the training platform | A records module inside the same platform that hosts the courses (pilots already have accounts and LMS completions already exist there): grade-sheet entry with sign-off, the matrix, self-service, scheduled alert jobs, SMS via Twilio. | One login for training and records; exam completions flow in automatically; PQS-native; the company owns the data. | Build and maintain it; alert delivery and backups become internal responsibilities. |
Recommendation: stand up Option 2 in the first 30 days so Flight Operations has visibility immediately; evaluate Option 1 in parallel for automated flight-log import against Draganfly’s actual log format; move to Option 3 only if the SaaS cannot model qualification rows or the LMS integration proves worth the build. Whatever runs underneath, the data model above is the contract — it is what makes the records portable between options.
Audit and change control
Every grade sheet is the PQS task table graded and signed, stamped with the PQS revision in effect. That preserves the chain an auditor or accident board walks in either direction: grade sheet → PQS revision → manual revision. When a manual revises, the standard identifies the affected rows, lessons, exams, and checklists, and which qualified pilots need a bulletin, differences training, or re-evaluation — with an effectivity date and an alert, through the same system.
Program health, measured from the same records
First-attempt pass rate per task (which lesson is weak), instructor grading variance on identical tasks (standardization health), time-to-qualification, currency compliance rate, time-to-field a training change after a product revision, and field safety findings traced back to task IDs. Each one closes a loop into the standard; none of them require a second system.