EASA EBT Data Exports: Grades, Versions and Assessment Gaps

Executive Summary

EASA EBT data exports are useful only when their assessment context survives export. For a professional pilot reviewing a training record, a grade without its competency definition, framework edition, assessment phase and grading legend cannot establish a like-for-like history. Under the European Union Aviation Safety Agency (EASA) framework, evidence-based training (EBT) operates through a competent-authority-approved programme; software export capability does not confer that approval. (Source: www.easa.europa.eu) The International Air Transport Association (IATA) also conditions a particular grade-comparison method on comparable module difficulty and standardized instructors or evaluators. ^[1]

The practical decision is whether the existing training product can supply interpretable evidence through its supported reports or export. SkyDynamics advertises configurable frameworks and historical imports (Source: skydynamics.aero) and training-record exports (Source: skydynamics.aero); Hinfact advertises keeping, exporting and archiving training data. These are vendor descriptions, not results of an independent migration test. ^[2] Start with those supported capabilities. A narrow adapter becomes reasonable only after a documented test identifies information that an authorized recipient needs and that configuration or a supported export cannot retain.

The worksheet below separates record completeness, semantic comparability and assessment outcome. Its synthetic example matches 117 of 120 eligible assessment records, or 97.5%. Those invented counts demonstrate reconciliation arithmetic, not an industry benchmark or an acceptable safety threshold. The unmatched records remain unresolved. Blank, absent and explicitly unobserved assessments stay distinct: EASA guidance discusses both competencies left blank during manoeuvres training and exceptional “not observed” grading. (Source: www.easa.europa.eu) Schema validation can help preserve that distinction because an explicit null and an absent property are different states. ^[3]

The recommended deliverable is an authorized export accompanied by its legend, versioned framework, coverage statement, correction history and reconciliation results. Metadata standards provide useful engineering patterns, without becoming aviation approval requirements. ^[4] Personal logbook evidence should remain separately identifiable from operator-held competency evidence. Access and correction rights also need separate treatment from conditional portability rights. (Source: commission.europa.eu) (Source: www.dataprotection.ie) The European Cockpit Association (ECA) emphasizes ownership, access and confidentiality in its EBT position; that is a pilot association's recommendation, not legislation. (Source: www.eurocockpit.eu) The resulting record should let a pilot and an authorized training representative explain what an assessment meant when it was recorded, including when an honest historical comparison is unavailable.

Introduction and Background

A captain receives a training-history export after changing fleets. Two entries show the same competency code and the same numeric grade. One was recorded during evaluation under an earlier framework; the other followed training under a revised definition. This is a hypothetical example. The numbers look consistent, but the export alone may not demonstrate equivalent evidence. The question is what the records actually describe.

That question matters to pilots keeping professional records as well as to the people who supply them. The International Civil Aviation Organization (ICAO), in its publicly available 2020 training procedures, describes assessment planning in terms of gathering valid, reliable evidence at different training stages. That edition supplies conceptual context here, rather than a claim about the latest ICAO text. (Source: www.icao.int) This report concentrates on approved European airline aeroplane EBT programmes. Helicopter practices and another jurisdiction's licensing procedures do not establish the scope of an individual EU operator's approval.

The regulatory reference checked for this report is EASA's March 2026 Revision 24 Air Operations collection. (Source: www.easa.europa.eu) Later material was checked too: the July 2026 Part-ORO Amendment 30 addresses training and simulator requirements in ORO.FC.145, rather than rewriting the ORO.FC.231/232 grading provisions discussed here. (Source: www.easa.europa.eu) EASA also lists Regulation 2026/781 as concerning flight simulation training devices and their use. (Source: www.easa.europa.eu) Its underlying legislative text remained inaccessible during this research, so this report does not independently establish its application schedule. A reader making a programme decision should confirm applicable amendments and the operator's approved arrangements with the responsible training department and competent authority. Programme assessment and oversight remain authority functions. (Source: www.easa.europa.eu)

This is an assessment-record analysis, not a licence revalidation calculator or a crew-assignment tool. Its proposed identifiers, status flags and tests are engineering choices, not prescribed EASA database fields. For pilots, the useful starting request is a supported copy of their own assessment evidence and its explanatory context. The publisher's Pilot Logbook belongs to the separate personal-record conversation; pilots interested in that category can request an invite. It is not presented here as an EBT assessment system.

Key Changes

Change the unit of comparison from a grade to an evidence package

An export review should start with meaning. The proposed comparison unit is a particular assessment of a particular competency, within an identified framework and phase. IATA's implementation guide explains how an adapted competency model adds performance criteria to the framework. ^[1] A competency code is therefore a lookup aid, not a sufficient description of the assessed performance.

Ask the training department for the legend and framework applicable when the assessment occurred. A current handbook can explain today's export but leave an earlier grade ambiguous. Preserve the historical wording separately from any current label. The ECA's position calls for clearly defined competencies and indicators before implementation, reinforcing the importance of an explicit model while remaining an association recommendation. (Source: www.eurocockpit.eu)

Change “file delivered” into a reproducible coverage statement

Delivery of a comma-separated values (CSV) file establishes that a file exists. It does not establish which assessment population it covers. The World Wide Web Consortium (W3C) explains that tabular interpretation requires additional metadata. ^[4] A practical coverage statement should identify the source product, export route, filters, historical period, included phases and extraction cutoff.

An assessment plan concerns valid and reliable evidence, as ICAO describes, so the review needs more than a successful download. (Source: www.icao.int) The pilot-facing question is straightforward: does this copy include every eligible assessment requested, and can the supplier explain every exclusion? A supporting training representative can answer it with a count reconciliation. An export without its denominator makes a percentage of completeness difficult to interpret. This report's denominator is defined explicitly in the synthetic worksheet below.

Change silent transformation into a documented decision

Before accepting an export or a migration, request these accompanying items:

• Coverage: the included pilot population, sessions, phases and historical dates.
• Definitions: the framework edition, competency descriptions and relevant observable behaviours.
• Scale: the applicable legend and its relationship to an assessment outcome.
• History: the treatment of corrections, superseded versions and later submissions.
• Ownership: a named role responsible for resolving disputed field meanings.
• Evidence: source references and a retained copy of the supplied export contract.

These are proposed acceptance criteria. National Institute of Standards and Technology (NIST) terminology describes provenance as metadata about a data source; that provides a useful technical basis for preserving source references without making NIST an aviation regulator. ^[5] A transformation log should explain whether an output value was copied, relabelled, translated, excluded or derived. The original value should remain recoverable within the authorized evidence package. Physical text and typed data can differ, a distinction made explicit in Frictionless Table Schema. ^[6]

Where a product already provides this information, retain its native report and documentation. Where it does not, first clarify the contract with the vendor. The missing capability should be described precisely enough to reproduce it with a synthetic record, before any integration work is proposed.

Competency Versions and Grading Comparability

Preserve identity before attempting a crosswalk

The framework specified in ORO.FC.231 includes competencies, descriptions and associated observable behaviours. (Source: www.easa.europa.eu) For reconciliation, this report proposes separate identifiers for the framework family, edition, competency and, where recorded, observable behaviour. The point is to make a definition change visible even when a familiar code remains unchanged.

Table 1 is a proposed source-to-export worksheet. Replace the illustrative field names with the names in the actual product documentation. Its metadata and uniqueness checks draw on W3C's tabular-data model, rather than an EASA export schema. ^[4]

The worksheet is a contract checklist, not a demand to rename every vendor field. A native report plus a versioned attachment may retain more meaning than a flattened table. W3C metadata provides a model for accompanying tabular values with interpretation information. ^[4] Preserve the supplied representation and document its interpretation. Frictionless Table Schema similarly distinguishes physical text representation from logical typed data, a useful way to describe such transformations. ^[6]

Preserve the scale and its regulatory status

AMC1 ORO.FC.231(d)(1), an acceptable means of compliance (AMC), recommends a 1 to 5 grading scale. (Source: www.easa.europa.eu) AMC2 describes demonstrating equivalence for an alternative grading system under ORO.GEN.120. (Source: www.easa.europa.eu) Neither statement establishes that a supplier's different scale is automatically equivalent. Keep its documented basis with the historical legend.

The distinction between a rule, AMC and guidance material (GM) matters. EASA describes AMC as non-binding standards and provides an alternative-means process. (Source: www.easa.europa.eu) The rule establishes the programme obligation; AMC describes a compliance approach; GM supplies explanatory guidance. For this worksheet, fields such as scale_version and status_meaning remain proposed implementation choices. Do not describe them as regulatory database requirements. IATA's adapted-model discussion provides a parallel reason to keep performance criteria with competency labels. ^[1]

Treat a mapping as a claim requiring evidence

Use the following classifications when comparing editions:

• Unchanged: the relevant definition, criteria and context are documented as unchanged.
• Renamed: the label changed and the documented assessment meaning was retained.
• Modified: wording or performance criteria changed enough to require review.
• Split or merged: a competency became several, or several became a new whole.
• Unresolved: available documentation does not support a comparability decision.

A changed label need not destroy comparability; an unchanged code does not prove it. Record the mapping decision, its authorizing role, supporting documents and permitted use. Preserving those references implements the source-traceability idea described in NIST provenance terminology. ^[5] IATA's comparison conditions also concern module difficulty and assessor standardization, so a framework crosswalk alone is insufficient. ^[1]

For a cross-fleet merge, retain fleet or aircraft context instead of silently pooling records. ORO.FC.232 makes assessment and training topics relevant to the aircraft type or variant. (Source: www.easa.europa.eu) Report separate groups when their equivalence has not been established. A combined chart should never imply a historical improvement merely because the source labels were successfully matched.

Implementation Considerations and Process Changes

Inventory supported options before commissioning an adapter

An existing training-management system (TMS) should be the first place to investigate. SkyDynamics describes historical imports, configurable competency frameworks and grading scales on its heads-of-training page. (Source: skydynamics.aero) Its aeroEBT product page states that training records can be exported. (Source: skydynamics.aero) Those statements establish advertised functionality; they do not verify a particular customer's historical export. Ask the supplier to demonstrate the actual supported route on the operator's authorized test data.

Other providers demonstrate why product terminology requires care. MINT describes integration capabilities, while CAE documents an eGrading application that pushes training data to a qualification-management system. ^{[7] [8]} MINT separately lists reporting formats including PDF, CSV and Excel. ^[9] Neither a generic integration claim nor an electronic form is proof that an export retains an earlier grading legend. Hinfact's electronic training-record page explicitly includes keeping, exporting and archiving data, but the interpretation of a specific export still needs to be checked. ^[2] These are examples of capabilities to investigate, not a vendor ranking.

Request evidence in a consistent sequence:

• Native report: obtain the ordinary supported assessment-history output.
• Export dictionary: ask for field meanings, types, keys and status values.
• Historical coverage: identify the earliest available records and any excluded modules.
• Version support: demonstrate retrieval of a superseded framework and grading legend.
• History support: demonstrate a corrected assessment and its source references.
• Access after change: document who can retrieve the old evidence after migration.

The decision should be based on the supported product version, relevant configuration and agreed scope. A vendor's public page is a discovery source, not an export acceptance certificate. A pilot requesting records need not prescribe the implementation; the training representative should be able to explain the supplied package.

Specify the supported format without inventing an EASA schema

The sources reviewed do not establish a universal EASA-mandated CSV or JavaScript Object Notation (JSON) export schema. Adopt an explicit local contract instead. W3C CSV metadata can declare null markers and row keys. ^[4] JSON Schema distinguishes an absent property from a property containing null, and its default treatment permits omitted properties unless a schema makes them required. ^[3]

A parser succeeding is only the first check. Require the correct identifiers, recognized phase values, referential links and documented status meanings. Preserve the raw export before transformation. RFC 8259 requires UTF-8 encoding for JSON exchanged outside a closed ecosystem, so verify character preservation in descriptions as well as numeric fields. ^[10] RFC 8259 says JSON object member names should be unique, making duplicated grade members a useful rejection test rather than an invitation to choose whichever value a parser returns. ^[10]

Keep time semantics and corrections explicit

An occurrence timestamp, an instructor's entry timestamp and the export timestamp answer different questions. A late submission should not be moved into a different training period simply because it synchronized later. RFC 3339 explains the information carried by a local offset from Coordinated Universal Time (UTC). ^[11] The contract should state whether the product supplies offsets, UTC values or dates without a time. Treating omitted properties as acceptable by default is a documented JSON Schema behavior; a local contract must explicitly require the timestamps needed for its purpose. ^[3]

For a narrow adapter, define the demonstrated gap, source and destination contracts, transformation rule, retained evidence and reconciliation result. Keep a rollback copy under the agreed access controls. NIST's provenance concept supports this traceability choice. ^[5] Commission custom work only after the supplier-supported route has been tested and the remaining loss has been documented.

Missing Assessments and Correction Histories

Distinguish “not assessed” from an assessment outcome

EASA's grading guidance distinguishes evaluation (EVAL), manoeuvres training (MT) and scenario-based training (SBT). (Source: www.easa.europa.eu) Its guidance allows limited competencies to be graded during MT while others remain blank, and exceptionally permits “not observed” grading in the specified assessment circumstances. (Source: www.easa.europa.eu) These distinctions should survive reconciliation. A blank is not automatically a failing grade, and an explicit unobserved state is not an ordinary numeric score.

Use separate classifications for different questions:

• Recorded grade: the source contains a grade under a known legend.
• Recorded unobserved: the source explicitly records that the competency was not observed.
• Recorded blank: the source leaves the assessment cell blank in its documented context.
• Not applicable: the source explicitly identifies an inapplicable item under its own rules.
• Absent record: an expected eligible assessment has no matched exported record.
• Unresolved state: a source value exists but its meaning has not been established.

The first categories describe source evidence. Absence describes a reconciliation finding. “Not applicable” is a proposed state to preserve if the source actually uses it, not a claim that every EBT programme requires that value. Frictionless schema rules show why declared missing markers need attention before type conversion. ^[6] W3C metadata also permits explicit declarations of the strings representing null. ^[4] If every blank-like string becomes null immediately, the evidence needed to distinguish those meanings may disappear.

Test the awkward cases deliberately

Table 2 contains synthetic records, a hypothetical example. All identifiers, editions and grades are invented. Each row describes a test pair, not a real pilot assessment. The approach uses the distinction between missing and explicitly null properties described in JSON Schema. ^[3]

A successful result preserves the distinctions, including an unresolved one. It does not need to convert every historical grade into a common number. For example, an arithmetic rescaling from a four-category scale to a five-category scale changes the display without demonstrating equivalent assessment criteria.

Ask the supplier to retain a correction link rather than quietly replacing history. An authorized current-state report may display the latest valid assessment while a history report retains the superseded record. The reconciliation should state which view it counts. Provenance provides the technical rationale for keeping the connection to the original record. ^[5] No test here assigns instructor performance thresholds or ranks pilots.

Personal Records, Access and Scope

Keep flight-time evidence separately identifiable

A personal logbook and an EBT assessment package answer different questions. The former records flight experience; the latter explains assessed competencies under an operator's programme. As a jurisdiction-specific illustration, the UK Civil Aviation Authority (CAA) permits electronic logbook copies for its licensing documentation process to be printed and signed by hand. This is UK guidance, not an EU submission rule. ^[12] A printable logbook format therefore should not be treated as proof that an exported assessment retains its framework and legend.

Pilots can organize both kinds of evidence without merging their meanings:

• Logbook copy: retain the flight or simulator-session record in the appropriate personal record.
• Assessment copy: retain the authorized report supplied by the training department.
• Explanatory context: keep its scale legend, framework reference and phase description.
• Correction request: identify the disputed source record rather than editing the supplied evidence.
• Access boundary: avoid collecting another pilot's identifiable assessment to make a comparison.

Pilot Logbook is relevant to the personal logbook category. It is not evaluated as a substitute for an operator's approved EBT records, and no product comparison table in this report treats it as one.

Separate access, correction, portability and retention

The European Commission explains personal-data access and rectification rights. (Source: commission.europa.eu) The Irish Data Protection Commission explains that portability has qualifying conditions; it should not be described as an unconditional entitlement to every operator-created export or a requirement for a vendor-specific schema. (Source: www.dataprotection.ie) The practical route is to ask the records holder which access process, authorized report and correction procedure apply.

Access to one's own evidence is also different from permission to receive an identifiable cohort dataset. The Irish Data Protection Commission describes data minimization and accuracy as data-protection principles. (Source: dataprotection.ie) The European Data Protection Supervisor (EDPS) distinguishes pseudonymisation from anonymisation; replacing a name with a code should not be presented as making the information anonymous. (Source: www.edps.europa.eu) EDPB guidance likewise states that truly anonymised data is no longer personal data, emphasizing why the distinction matters. (Source: www.edpb.europa.eu) Keep re-identification information and recipient permissions within the agreed governance arrangements.

Retention needs record-category analysis. EASA's retention FAQ identifies a three-year period for the specified crew training, checking and qualification records. (Source: www.easa.europa.eu) That does not establish one period for every analytical derivative, migration snapshot or correction trail. Ask the responsible records and data-protection specialists to document the applicable category, purpose and access after a system change. Irish DPC guidance recommends erasure or periodic-review time limits, rather than an indefinite archive. (Source: dataprotection.ie) ECA's position on ownership, access and confidentiality adds pilot-representative context without supplying a separate legal retention rule. (Source: www.eurocockpit.eu)

Data Analysis and Evidence

Define the denominator before calculating completeness

There is no measured industry export-success rate in the evidence assembled for this report. The quantitative contribution is a reproducible synthetic worksheet, not a market statistic. Start by agreeing what an assessment unit is, which source records are eligible and which export versions count as current. W3C's primary-key model supports checking uniqueness once that unit is defined. ^[4]

For this hypothetical example, an assessment unit is one competency assessment for one participant, in one identified session phase, using one framework edition. An approved source-side list defines eligibility. Cancelled sessions are excluded before counting; explicitly recorded unobserved assessments remain eligible records where the source list includes them. This tests preservation of evidence, not whether a pilot met a performance criterion. If an intended assessment never existed in the source, this ratio cannot reveal that training-coverage gap. Keep an operator-defined expected-assessment check separately, and leave an absent source assessment ungraded rather than inventing an outcome.

Table 3 shows invented counts for a hypothetical example. “Corrected current” is a subset of matched current records, not an additional category to add to them.

For these invented figures, completeness is matched unique eligible source assessments divided by all eligible source assessments: 117 / 120 = 97.5%. EVAL is 58 / 60 = 96.7%, rounded to one decimal place; MT is 29 / 30 = 96.7%; SBT is 30 / 30 = 100%. None is a regulatory threshold. Even a full match would establish record coverage under this definition, not comparable grading or programme approval.

Reconcile export rows separately from assessments

Suppose the same hypothetical export contains 125 raw rows: 117 current matched rows, four superseded versions, two duplicate deliveries and two out-of-scope rows. Those categories sum to 125. The three unmatched source assessments are absent from the export, so they are not another export-row category. Treating all raw rows as current assessments would overstate the numerator.

A useful reconciliation note should explain each discrepancy:

• Coverage mismatch: the export's date or population filter differed from the agreed source list.
• Late submission: a newly entered record requires a later authorized extraction.
• Correction chain: multiple versions represent one assessment in the current-state count.
• Duplicate delivery: repeated transport did not create another source assessment.
• Unresolved absence: no authorized explanation yet accounts for the missing assessment.

After count reconciliation, partition matched records by framework edition, scale, phase and relevant population. IATA's guidance adds comparable difficulty and standardized assessors to its comparison assumptions. ^[1] Thus, a complete set of matched identifiers can still contain noncomparable groups. Report those groups explicitly rather than averaging them into a single historical trend.

The public provider pages examined describe capabilities, not an independent benchmark of this worksheet. MINT's integration description and Hinfact's export description are reasons to request a demonstration, not numerical evidence of completeness. ^{[7] [2]} No time savings, migration failure rate or safety improvement is inferred from this synthetic arithmetic.

Implications and Future Directions

A useful export specification should make future uncertainty manageable. When a framework changes, preserve the previous edition and attach a documented relationship to the next. When a scale changes, retain the old legend rather than rewriting every earlier value. When an export contract changes, identify the contract version so a historical file can still be interpreted. These are proposed design practices; the underlying metadata problem is the one W3C addresses when describing how tabular data should be interpreted. ^[4]

The immediate purchasing decision is usually modest: establish what the existing product can supply, configure it, and test its supported export. SkyDynamics' advertised configuration capabilities and CAE's eGrading documentation show why a native-product investigation is a reasonable first step. (Source: skydynamics.aero) ^[8] They do not settle an individual operator's acceptance decision. That requires evidence from the supported route and the historical records actually in scope.

For professional pilots, the strongest request is specific: an authorized assessment history, applicable legends, phase context and a way to correct an inaccurate source entry. European Commission guidance provides the access and rectification context; ECA supplies the pilot association's emphasis on confidential, clearly governed evidence. (Source: commission.europa.eu) (Source: www.eurocockpit.eu) A personal archive should make the origin of supplied records clear and preserve explanatory attachments. Those attachments complement the formal evidence-gathering role described in ICAO assessment planning. (Source: www.icao.int)

For the training team, the corresponding deliverable is a concise reconciliation statement: coverage agreed, records matched, differences explained, comparison groups documented and unresolved gaps retained. If a narrow adapter remains necessary, define its purpose against that statement. An adapter should preserve source meaning and traceability, not create unsupported equivalence between grading systems. RFC 3339 timestamp conventions and explicit schema rules are available engineering aids, not evidence that software can approve an EBT programme. ^{[11] [3]}

Conclusion

The central question for EASA EBT data exports is whether the recipient can explain an assessment in its original context. A grade needs its framework, competency definition, phase and legend. A historical comparison needs an additional documented basis for treating records as comparable. A missing exported record needs an explanation separate from a recorded blank, unobserved state or assessed outcome.

The proposed worksheet turns that question into reviewable evidence. Inventory the supported report and export first. Record the source-to-export mapping, identify the historical editions, preserve corrections and reconcile an agreed population. Then state which matched assessments can be compared and which remain separate. The synthetic arithmetic demonstrates how to account for missing records without converting a completeness percentage into a safety threshold.

For a professional pilot, the practical outcome is a more intelligible personal evidence package and a precise route for asking the records holder about an ambiguity. For the training department, it is a clearer explanation of what an export preserves. Flight-time records, assessment evidence and programme approval retain their separate purposes.

Configuration and vendor-supported output should precede custom integration. Where a demonstrated gap remains, a narrow adapter may address that gap under the agreed access arrangements. The acceptance test is preserved meaning, supported by traceable evidence, including an explicit statement when the available history does not justify comparison.