Ask an ops manager whether a given pilot is "current" and you have already asked the wrong question. A crew member is never simply qualified — they are qualified for a specific flight. The same captain can be perfectly legal on a Part-NCC positioning leg this morning and non-compliant on a commercial charter with the same aircraft this afternoon, because the second flight pulls in requirements the first one never triggered. That is the core reason crew qualification tracking is so much harder than it looks, and why spreadsheets and per-person checklists collapse under it.
If there is one sentence to remember from this article, it is this: crew qualifications don't expire against the calendar; they expire against the flight.
Why the naive approach breaks
The intuitive model — a folder or spreadsheet per crew member, listing documents and expiry dates — treats validity as a personal attribute. It fails on several predictable fronts:
The requirement set is contextual. Under Part-FCL (Reg. (EU) No 1178/2011), a type rating attaches to an aircraft type; a licence class and medical attach to the person; recent experience under FCL.060 attaches to a role on a category of operation; and FCL.065 curtails commercial air transport privileges from age 60 and removes them at 65 — meaning the same pilot with the same paperwork may be legal for a private flight and not for a commercial one, purely as a function of the flight's nature and his own date of birth on the day of departure. A person-centric list has no way to express any of this.
Expiry arithmetic is not "issue date plus twelve months." EASA revalidation rules are deliberately anchored to the old expiry date: pass a proficiency check within the three months preceding a rating's expiry under FCL.740 and the new period counts from when the old one would have ended — do it earlier, and the clock restarts from the day of the check. Part-MED medicals follow the same anchoring logic with a 45-day revalidation window under MED.A.045, but to the exact day. Operator recurrent checks under ORO.FC.230 (Reg. (EU) No 965/2012) use yet another calendar: validity counted from the end of the month in which the check was taken, again with a three-month window preserving the original expiry date. Three document families, three different arithmetics — and every manual entry of a new expiry date is an opportunity to apply the wrong one.
Change doesn't scale. When the operator adds an aircraft type, wins an AOC variation, or the training department tightens a recurrent requirement, a person-centric system requires touching every affected crew file individually. Somewhere between crew member 20 and crew member 60, one file gets missed — and the miss stays invisible until the day that person is assigned to exactly the flight where it matters.
The failure mode is silent. Nobody notices a stale spreadsheet cell. The error surfaces as a crew member airborne without a valid required document, which is not an administrative embarrassment but a finding against the operator's management system under ORO.GEN.200 of the Air OPS regulation — and, in the worst case, an insurance problem.
The practical takeaway: any tracking approach where a human recomputes expiry dates or maintains requirements person by person has a built-in error rate. At small scale you can absorb it with vigilance. Beyond roughly 40 crew members, a rules engine stops being a convenience and becomes a safety control — without one, a crew member flying on lapsed paperwork is a matter of time, not probability.
What a mature system does instead
A mature flight management system inverts the model. Instead of asking "what documents does this person have?", it asks "what does this flight require, and does this person satisfy it right now?" That inversion rests on four pillars.
1. Requirements are rules, not lists
Each certificate or training item is defined once, together with the conditions under which it is required. In practice, business aviation crew planning needs a surprisingly rich attribute space for those conditions. A well-designed rules engine lets the operator scope a requirement by:
-
aircraft — by type or by individual tail (a distinction that matters: an RVSM monitoring item may be per type, a client-mandated training per registration);
-
AOC — which operating certificate the flight is conducted under, essential for multi-AOC operators;
-
crew function — cockpit vs cabin vs ground vs maintenance, or specific positions;
-
nature of the flight — commercial vs private, and the trip type itself (passenger charter, cargo, ferry, ambulance, training);
-
ICAO flight type — scheduled, non-scheduled, general aviation;
-
licence type and language proficiency level — so an ATPL-only or Level-6-only requirement never fires against crew it doesn't concern, mirroring FCL.055;
-
crew age at the date of the flight — minimum and maximum, which is exactly how FCL.065 age limits behave in the real world;
-
employment relationship — regular crew vs freelancers, who often sit under a different compliance regime;
-
named exceptions — explicit include/exclude lists for the genuinely individual cases.
Airport-specific competence — category-C briefings, online familiarisation, practical training — deserves its own dedicated mechanism, checked separately against departure, destination and alternates of each sector, because that is where the requirement actually bites. In Leon this whole rule layer is configured under crew certificates, where a certificate definition carries exactly this kind of scoping rather than being a bare document type.
The payoff for the planner: the question "which documents does this assignment need?" is answered by the system, per sector, instead of living in someone's head.
2. Validation runs per flight, live
The check itself must be evaluated against the concrete leg: its date and time, its aircraft, its AOC, its commercial status, its trip type — and the crew member's attributes as of that date, age included. Two consequences follow. First, the "valid here, invalid there" situation is represented honestly instead of being flattened into a single per-person status light. A crew member's profile in the ops view can show which items are required for dispatch on this particular flight and which are merely informational. Second — and this is the part that makes rules genuinely scalable — when a rule is evaluated live rather than cached per person, changing the rule changes reality everywhere, instantly. Add a new aircraft type to a requirement's scope and every future assignment on that type is re-checked from the next screen refresh, across the whole crew list, with no batch job and no per-profile edits. One change, fleet-wide effect, zero opportunity for a missed file. This is the single strongest argument for rules over profiles: a requirement changed in one place is a requirement changed for everyone.
For the ops manager, that means change management collapses from a project into an edit.
3. Expiry dates are computed, never typed
Manually overwriting an expiry date after each recurrent check will, sooner or later, produce a wrong date — the only open question is when. The expiry date should always be derived by the system from two inputs: the revalidation date and a declared revalidation policy. A duty-aware system encodes the policies the regulations actually use: exact-day validity, as Part-MED medicals use; end-of-month counting, as Part-ORO recurrent checks use; base-month schemes where validity is anchored to a fixed month of the year; day- or month-based validity units; and — critically — the revalidation window itself, so that a check performed inside the window extends validity from the previous expiry date, while one performed outside it starts from the actual date. Grace periods can be modelled explicitly too, as a state that warns rather than violates. Done this way, the training coordinator records one fact — "checked on this date" — and the system does the regulatory arithmetic; operators can even simulate a planned revalidation date and preview the resulting expiry before committing it.
One subtlety separates careful implementations from careless ones: changing a certificate's validity period must not retroactively rewrite already-issued documents. A configuration edit should never silently "extend" someone's medical; the new period should apply from the next real revalidation. That asymmetry — rule scoping propagates instantly, but issued validity is immutable until re-earned — is precisely the right safety posture.
The takeaway for the planner: dates you never type are dates you never mistype.
4. The system warns early, distinguishes states, and escalates
A binary valid/expired flag is too crude for planning. The states that matter operationally are at least four: not applicable (the rule doesn't match this person or flight), valid, expiring soon or within a grace period, and violated — with "never issued" treated as seriously as "expired", because operationally they are the same exposure. Those states should surface where decisions are made: as warnings when a flight is saved or crew is assigned, as colour status in the crew and planning views, and as proactive expiry notifications e-mailed to both the certificate owner and the people who manage compliance, on per-rule intervals. For audits and client reporting, the same data should be queryable in bulk — expiring-in-90-days reports, qualification matrices, missing-certificate checks — the kind of output an endorsement reporting scope exists for.
Whether an invalid certificate is a warning or a hard block is ultimately an operator's policy decision — but the system's job is to make the state impossible to miss at the moment of assignment, not to discover it in a post-flight audit.
The test to apply
Put any crew qualification tracking tool — including a spreadsheet — through four questions. Can it express for which flights a document is required, across aircraft, AOC, role, flight nature and crew attributes? Does it evaluate that requirement against each individual sector, live? Does it compute every expiry date from a declared revalidation policy instead of trusting a typed-in date? And when a requirement changes, does the change reach every crew member at once?
It's the philosophy we've built crew qualification management around at Leon Software — but whichever flight operations software you use, the test above is the right one to apply. Because in business aviation there is no such thing as a qualified pilot in the abstract. There is only a pilot qualified for this flight — and a system that knows the difference.