Currency & Training Records

Flight Operations needs to see, at a glance, who is current to fly what — and needs to know before something expires. 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 record behind every currency status — the signed grade sheet or logged training event that proves it.

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 — the signed grade sheet is the record	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 learning management system (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 an FAA Part 107 recurrent completion certificate, acknowledge an alert, from a phone. Everything else — grade sheets, exam results — enters the system digitally at the source.
Instructor / Evaluator	Enter and sign grade sheets (the Platform Qualification Standard (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 to the pilot at 60 and 30 days before expiry, email and SMS at 14, 7, and 0; 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”).

Prototype

The standard as data

Every task in the Platform Qualification Standard (PQS) has an ID. That ID ties the records together: it appears in the standard, on every graded line of every grade sheet, and on every exam question in the learning management system (LMS).

Proposed mechanics: a grade sheet is generated from the syllabus — each flight lesson lists the PQS tasks it covers, and the sheet for that lesson is those tasks laid out as lines to grade. The evaluator grades on a phone or tablet form at the debrief and the student acknowledges the result on the spot; where a site has no connectivity, a printed sheet entered the same day is the fallback. Signed, the sheet is the qualification record. A sample from a Heavy Lift flight lesson:

Task ID	Task	Grade	Remarks
HL.VI.3	Manual takeoff & hover	Q	—
HL.VI.4	Manual flight maneuvering	Q	—
HL.VI.6	Commanded RTL (return to launch)	F	Prompted for the landing-zone assessment callout
HL.VI.7	Manual landing	Q	—
HL.II.2	Emergency landing	Q	Introduced this lesson — instructor-demonstrated, then student-flown

Grades use the Q / F / U scale from the grading standard. The signed sheet carries the evaluator signature, student acknowledgment, and date.

Because every graded line and every exam question carries a task ID, the records can answer pass rate per task across all students, grading spread per instructor on the same task (the data behind the calibration sessions on the Instructor Standardization page), and time-to-qualification per program. Generic records software tracks certificates and dates and has no place to store a graded task line. Any option below has to store it, or that measurement is lost.

When a source manual changes

Every task in the PQS cites the manual section it is built from, and that citation is kept as data: a register of document × revision × affected tasks. When a revised manual is issued (the Heavy Lift Operator’s Manual is at Revision 1.1 today, the Herelink GCS Pilot’s Manual at 1.2), the register lists every task whose source section changed, and each gets a training impact assessment: no training change, a courseware update, or differences training. Where differences training is required, it is published as a dated currency item on the same alert schedule as every other dated item on this page. Every grade sheet is stamped with the PQS revision in effect when it was signed, which preserves the chain an auditor or accident board walks in either direction: grade sheet → PQS revision → manual revision.

How to build it — three options

Three real ways to run the data model above: buy, assemble, or build.

Option	What it is
1. Buy — existing drone-operations software (SaaS)	DroneLogbook or AirData — commercial drone-operations platforms with pilot currency tracking, expiration alerts, flight-log import, and compliance reporting. Fastest path to mobile apps and currency events that populate themselves; the trade is that currency rules must fit the vendor’s model, grading against individual PQS tasks is unlikely to be native, compatibility with Draganfly’s Cube/DGCS flight logs must be verified, and the data lives with the vendor at a per-seat cost.
2. Assemble — 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 and shaped exactly to the qualification standard — a working matrix in the first 30 days; the trade is that edits are logged but records are not signed, someone has to own it, and scaling and access control take competence to execute properly.
3. Build — a records module on the training platform	A records module inside the platform that already hosts the courses: grade-sheet entry with sign-off, the matrix, pilot self-service, scheduled alerts, SMS via Twilio. One login for training and records, exam completions flow in automatically, and the company owns the data; the trade is that building and maintaining it — alert delivery and backups included — becomes an internal responsibility.

Program health, measured from the same records

Beyond the per-task measures above, the same records give the currency compliance rate, the time to field a training change after a product revision, and field safety findings traced back to task IDs. No second system is required.

What is settled, and what depends on the operation

The data model and the alert logic above are settled: they are the same whatever software runs underneath. What picks the tool is the operation itself — how many pilots and customers the system carries, whether Draganfly’s flight logs export in a format that can populate currency automatically, what the company already licenses, and how manual revisions are handled today.

The method also has to work on paper: run as a spreadsheet, a shared drive, and a calendar reminder, the data model is identical and only the labor changes.