It is one of the more frustrating calls an office can get. A technician who has been working all season, whose qualifications are current, who was on a job for another operator last week, is standing at a gate and cannot get on site. Nothing expired. Nobody made a mistake in the field. And yet the crew is down a person and the day is already behind.
This happens often enough that it is worth being precise about why, because the usual explanation — "somebody let something lapse" — is frequently wrong.
Qualification is per-operator, not per-person
The instinct is to think of Operator Qualification as a property of a person: either someone is OQ current or they are not. In practice, it is a property of the relationship between a person, a specific covered task, and a specific operator.
Each operator defines its own list of covered tasks, decides which evaluation methods it accepts, sets its own re-qualification intervals, and maintains its own view of which training providers it recognizes. Two operators working the same kind of system can require materially different things from the same technician doing the same job.
So a technician can be entirely current for the operator they worked for last week and short a task for the one they are standing in front of today. Nothing lapsed. The requirement simply changed when the job changed.
The four gaps that produce most gate refusals
First: a covered task that was never on the tracker. The internal list was built from one operator’s requirements and then reused. Tasks that only one operator cares about quietly never got added.
Second: an evaluation that exists but is not the accepted type. A written evaluation on file where that operator requires a performance evaluation, or an evaluator whose credentials that operator does not recognize.
Third: a record that exists in one system and not another. The training facility has the certificate. The internal tracker has it. The network profile the operator actually checks does not, because that step is manual and was missed.
Fourth: an interval that is shorter than assumed. Re-qualification periods differ, and a technician tracked against the longest interval in use will drift out of currency for the operators using shorter ones — while the tracker still shows green.
Why spreadsheets specifically fail at this
None of these are hard problems individually. They are hard collectively because the correct data model is three-dimensional — person by task by operator — and a spreadsheet is two-dimensional. The third dimension gets flattened, usually by tracking against whichever operator was most demanding at the time the sheet was built.
That flattening is invisible while the operator mix stays stable. It surfaces the moment you take work from someone new, which is to say, exactly when you least want a surprise.
What actually fixes it
The structural fix is to stop maintaining a list of qualified people and start maintaining a matrix: for each operator you serve, the tasks they require; for each person, the evaluations on file, their type, their evaluator, and their expiry. Readiness then becomes something you can compute rather than something you believe.
Once that matrix exists, the monitoring becomes mechanical. Checking whether every person assigned to next week’s job is clear for that specific operator is a query, not an afternoon. Expirations can be surfaced with enough lead time to schedule re-qualification rather than react to a refusal.
That is the part most contractors never get to, because building and maintaining the matrix by hand is more work than the spreadsheet it replaces. It only pays off when the checking is automated — which is the argument for treating compliance as a data problem rather than an administrative one.
If you have had a gate refusal in the last year that nobody saw coming, it is worth working out which of the four gaps above caused it. In our experience it is almost never carelessness in the field. It is almost always the tracker being structurally incapable of representing the question being asked of it.