Why "Currency Expired" Is the Wrong Question for Scheduling Software

Most flight-school software, ours included, tracks currency the same simple way: a date field, a comparison against today, a red badge when it's past due. That's the right answer for some things — a medical certificate genuinely does just expire on a fixed date. But a lot of the rules that actually govern whether someone can legally fly aren't a single date at all. They're compound conditions evaluated over a rolling window, with alternate paths and exemptions built in. Treating them as a single expiry date isn't a simplification — it's a different, less correct rule that happens to look similar in a UI.

Here's a concrete example, worked through in enough detail to see exactly where the naive version breaks.

The rule: EASA FCL.740.A, revalidating a class rating "by experience"

Under EASA's Part-FCL (Commission Regulation (EU) No 1178/2011, as amended), a single-engine piston class rating is valid for a fixed period — commonly two years for SEP(land). So far, that part really is just a date. The interesting part is how a pilot keeps it valid without sitting a test with an examiner.

Per FCL.740.A(b)(1)(ii), revalidating "by experience" (rather than by proficiency check) requires, within the validity period of the rating:

• 12 hours of flight time in the relevant class,
• including 6 hours during the 12 months immediately preceding the expiry date — not just anytime in the validity window,
• 6 of those hours as pilot-in-command,
• 12 take-offs and 12 landings, and
• at least 1 hour of refresher training with a flight instructor or class rating instructor — unless the pilot already passed a proficiency check or skill test during the period, in which case this is exempted.

The UK CAA's own published guidance on this point is direct about the practical effect: refresher training isn't automatically required just because a rating has technically lapsed — the examiner or instructor is expected to use judgment about how much retraining an individual pilot actually needs, based on experience and how long it's actually been.

What this means for a piece of software trying to check it

A system that stores "class rating expiry: 14 March 2027" and turns red after that date has encoded roughly a fifth of the actual rule. It hasn't captured:

• That there are two valid paths to staying current (by experience, or by proficiency check), not one
• That the "6 hours" sub-condition has its own, different rolling window (12 months, not the full 2-year validity period) nested inside the outer one
• That "12 hours" needs to be tracked as actual flight time in the correct class specifically, not flight time generally
• That the refresher-training requirement is conditional on a separate fact (was there a recent proficiency check) that lives in a different record entirely

None of this is exotic. It's the normal shape of aviation currency rules once you look past the ones that genuinely are simple. Night currency requirements, instrument currency, instructor revalidation privileges under FCL.945 — most of them have this same structure: an outer validity window containing one or more inner rolling-window sub-conditions, sometimes with an alternate path that bypasses part of the requirement entirely.

The actual algorithm shape (not code — the logic)

Stated plainly, correctly checking a rule like FCL.740.A(b)(1)(ii) means evaluating, for a given pilot and a given date:

1. Is the rating still within its outer validity window at all? If not, this whole path is irrelevant — a proficiency check is required regardless of hours flown.
2. Sum qualifying flight time in the correct class across the full validity window. Is it ≥ 12 hours?
3. Of that time, sum only the portion that falls within the trailing 12-month sub-window ending at the expiry date. Is it ≥ 6 hours?
4. Of the same full-window total, sum only PIC time. Is it ≥ 6 hours?
5. Count take-offs and landings in the correct class across the window. Is each ≥ 12?
6. Check whether a proficiency check or skill test occurred within the window. If yes, the refresher-training condition is satisfied automatically; if no, separately confirm at least 1 hour of dual instruction with a qualified FI or CRI exists in the window.

Every one of those six checks needs its own correctly-bounded date range, and steps 2 and 3 need the same underlying flight log filtered two different ways. Get the window wrong on any single line — count from validity start instead of expiry date, say, or forget to exclude non-PIC time from step 4 — and the system will confidently tell a pilot they're current when they aren't, or block someone who's actually fine.

Where this still needs a human, not just a better algorithm

It's worth being honest about where the automation genuinely stops. Two things in FCL.740.A resist being fully mechanized even with a correct implementation of the six steps above:

First, the exemption logic touches judgment calls that live outside any database — an examiner deciding how much refresher training an individual pilot actually needs, informed by experience the instructor has of that specific person, isn't something a rule engine should be trying to replace. The regulation itself is written to expect exactly that judgment, not to eliminate it.

Second, revalidation by proficiency check is a different path entirely, gated on an examiner's sign-off that no scheduling system can independently verify — it can track that a check occurred and when, but the actual pass/fail determination happens in the aircraft, not in software.

Where we honestly are with this today

FlightDesk AI currently tracks currency the way most tools do — validity/expiry dates for medical certificates, licences, and English-language proficiency, with booking-time validation that blocks assigning an instructor or student whose recorded date has passed. That's step 1 of the six above, correctly implemented, and it already catches a real, common failure mode: someone getting scheduled after their medical or licence has quietly lapsed because nobody was watching the calendar.

The full rolling-window, multi-condition version — automatically computing FCL.740.A-style revalidation-by-experience directly from the flight log, rather than relying on someone to manually re-enter a new expiry date after the fact — isn't built yet. It's a genuinely different, larger piece of engineering than a date comparison, for exactly the reasons worked through above, and it's on the list precisely because the gap between "checks one date" and "correctly encodes the actual rule" is real and worth closing properly rather than papering over.