You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Collect pilot metadata and join it to telemetry for clustering #214
Is your feature request related to a problem? Please describe.
The client wants pilot rating and flight hours to factor into clustering. Neither exists anywhere in the repo, and there is no place to put them.
Describe the solution you'd like
A small CSV keyed by pilot_id with certification_level, flight_hours and pilot_rating, plus a loader in inference/ that joins it to the telemetry at feature engineering time. Handle missing pilots without dropping their telemetry silently.
Additional context
Field definitions are in docs/telemetry_schema.md section 4b. Depends on #211 for the join key. The category set for certification_level (Student, Private, Commercial, ATP) still needs confirming, and so does whether pilot_rating is a licensing rating or an evaluative score, which changes its column type. Both questions are with the client.
Validate certification_level against an ordered category list and map it to an ordinal 0-3 (Student, Private, Commercial, ATP). The set is still to be confirmed with the client.
Store pilot_rating as a string and keep it out of clustering until the client says whether it is a licensing rating or an evaluative score. Keep a single clearly named place to change that.
Pilots missing from the metadata are reported rather than silently dropped.
@jmacd867 the join key is in review as #219. Columns are pilot_id and flight_id, written by data_logger.py into every row, so you can build the join against those names now.
Answers from the client meeting (`docs/client_meeting_notes.md`):
Pilot rating is the type of certification, not a score. So it is not an evaluative score and the column can stay a string. Still unclear whether it differs from `certification_level`.
The client will send certification level, total flight hours and rating, for the pilots in the sample.
For performance groups, the client prioritizes total flight hours over certification level.
The client agreed to metadata being used at the end, to interpret groups and not to form them. This matches ADR 0001.
The client did clustering by hand last year and wants it automated.
The `certification_level` category set (Student, Private, Commercial, ATP) is still to be confirmed.
Activity
jmacd867 commentedon Oct 3, 2026
certification_levelagainst an ordered category list and map it to an ordinal 0-3 (Student, Private, Commercial, ATP). The set is still to be confirmed with the client.pilot_ratingas a string and keep it out of clustering until the client says whether it is a licensing rating or an evaluative score. Keep a single clearly named place to change that.Phlabry commentedon Oct 5, 2026
@jmacd867 the join key is in review as #219. Columns are
pilot_idandflight_id, written bydata_logger.pyinto every row, so you can build the join against those names now.jmacd867 commentedon Oct 16, 2026
Answers from the client meeting (`docs/client_meeting_notes.md`):
The `certification_level` category set (Student, Private, Commercial, ATP) is still to be confirmed.