EBT.ID

In many airlines the programme, training elements, scenarios, session results, training history, qualification dates and programme coverage sit in separate files kept by separate people.

A whole picture appears only after someone merges the data by hand, often right before a board or a check.

In that setting the decision on who to train next, and in what, rests on the last session and on the instructor’s memory. Weak areas that repeat across one pilot, a group or a module have to be found by hand.

EBT.ID brings the working processes of the instructor and the methodologist together: programme structure, training elements and scenarios, competency assessment, training history, the pilot profile and programme coverage.

Assessment forms carry the methodological rules inside them. Approved editions of a programme stay unchanged; a change is issued as a new version.

Over the operational loop runs the training-need calculation. A below-standard grade with a causal review forms an individual need. Accumulated results across modules and assessments reveal a need at group level.

The lifecycle engine creates modules, watches windows and deadlines, tracks qualifications and prepares renewal drafts. The working list sorts obligations by urgency: pilot, module, session, deadline.

The interface is built for tablet work. Key actions are available by tap. Element sizes match touch control.

• Programme, scenarios and competency model under version control.
• Assessment forms requiring observed behaviours, a causal review and a training need wherever the scale calls for them.
• An electronic signature over the form with a checksum of the content; a correction to a signed record is issued as a new version stating the reason.
• The lifecycle engine: module windows, deadlines, qualification expiry, renewal drafts and the effect of remedial work.
• A planning list and an attention queue on the heat map; early attention is counted apart from the main priority.

The system takes training data and operational features: the flight-data event catalogue with thresholds, flight hours, crew composition and qualification reference data.

What a given operator has to supply in place of the demonstration set is kept in a separate data register.

HR systems and the SMS stay external. EBT.ID exchanges data with them and does not take over their functions.

Release to line duty follows from the competence level recorded in the scale value, under AMC1 ORO.FC.231(d)(1). A second parallel release flag is left out, so that two independent states cannot drift apart.

Accumulated results across modules and assessments form a training need under AMC4.

The regulatory minimum and the operator’s internal standard are held apart. Numeric thresholds live in settings and carry their source. A value the primary source does not confirm is marked as an initial hypothesis and can be changed without touching the code.

The arithmetic mean of an ordinal grading scale is not used: values are ordered, and the distances between them are not equal.

Computed conclusions come from deterministic rules. Each rule carries a version, methodological grounds and three test scenarios: it fires, it stays silent, it meets a boundary case.

A trained model and a deterministic rule are treated as different mechanisms. A model fitted on data and lacking validation cannot be the only ground for a decision.

The «Algorithm boundaries» screen shows the provenance of every conclusion and the closed list of decisions the algorithm may not take on its own.

Every computed value carries its provenance, its type of mutability and the value actually applied. A result can therefore be reproduced after a setting or a rule version changes.

There is no summary rating of an instructor anywhere, exports included. «Insufficient data» stands as a result in its own right and is never replaced by a forecast or an extrapolation.