IATA Delay Codes in Operations Systems: Editions and Audits

Executive Summary

International Air Transport Association (IATA) delay codes in operations systems support defensible performance analysis when the system retains the reported coding scheme, edition, cause minutes and revision history. A code label alone cannot establish that records from different stations mean the same thing. EUROCONTROL's Air Transport Operator Data Flow (AODF) specification, EUROCONTROL-SPEC-180, edition 1.0, dated 25 February 2020, provides a useful public baseline: several causes can be reported with corresponding durations, and its duration check permits a total below the departure-delay measure. (Source: www.eurocontrol.int) This report proposes a data contract for evaluating that capability, rather than reproducing a current licensed code dictionary.

Edition awareness matters now. IATA identifies its 2026 Airport Handling Manual (AHM) as the 46th edition, while its public manual page advertises changes for the 47th edition, 2027. ^{[1] [2]} The Aviation Intelligence Portal's widely available code reference cites AHM 2012. (Source: ansperformance.eu) These references serve different purposes; none establishes which edition an imported record actually used. EUROCONTROL also describes AHM732 through Process, Reason and Stakeholder layers, so collapsing every representation into a legacy code loses potentially meaningful distinctions. (Source: www.eurocontrol.int)

The quantitative stakes concern interpretation, not a promised software benefit. EUROCONTROL's Central Office for Delay Analysis (CODA) reports 17.5 minutes of departure delay per flight in 2024, with reactionary delay accounting for 46% of delay minutes, or 8.0 minutes per flight. (Source: www.eurocontrol.int) (Source: www.eurocontrol.int) That aggregate share does not identify an upstream cause for an individual leg. The United States Bureau of Transportation Statistics (BTS) uses broad categories, while its 2026 technical directive requires reported minutes to equal arrival delay. ^{[3] [4]} A departure-attribution record therefore cannot be converted to BTS reporting by substituting category names alone.

The recommended decision is to test the existing platform first. Bytron skybook publicly documents edits to signed-off sector reports, and its FAQ describes an edit audit trail. (Source: www.bytron.aero) Where native configuration and exports preserve the required fields, an additional adapter offers little justification. A narrow integration becomes appropriate when a demonstrated exchange gap remains. LANDING.AERO describes custom flight operations software and data integration, making commissioned integration a possible route rather than a packaged code-management product. (Source: www.landing.aero) (Source: www.landing.aero) Acceptance should require original payload access, explicit unknowns, linked revisions and reproducible mappings. Grouped reporting remains separate from root-cause assessment and legal responsibility.

Introduction and Background

An operations control centre (OCC) may receive a station report, a ground-handler message and a crew post-flight record for the same departure. The practical question is whether those records can support the same analysis after imports, edits and aggregation. Public explanations from OAG already describe delay-code families, and Bytron describes configurable codes matching an operator's internal standards. ^[5] (Source: www.bytron.aero) The additional analytical need is to retain the context behind each submitted value.

This report separates source coding, aggregate reporting and causal interpretation. Source coding records what a particular actor reported under a particular scheme. Aggregate reporting groups those records for a defined population and measure. EUROCONTROL explicitly describes including individual codes in groups to clarify analysis. (Source: www.eurocontrol.int) Causal interpretation asks what evidence explains a particular disruption. A reporting group is an input to that inquiry, not its conclusion.

The proposed worksheet is intended for OCC and performance managers, station data owners and integration staff. Its acceptance criteria are design recommendations, not an assertion that IATA mandates a particular database or retention policy. General software standards provide useful mechanics: World Wide Web Consortium (W3C) Provenance Ontology (PROV-O) distinguishes attribution to an agent from a revision relationship, while CloudEvents offers a common event envelope. ^{[6] [7]} Neither standard supplies airline attribution policy.

The public evidence was accessed on 13 October 2026. The central limits are explicit: the current licensed AHM dictionary and subcodes were not publicly verified; the receiving AODF implementation may differ from the published specification; and operator rules must determine allocation, evidence access and revision approval. IATA's store conditions describe products as licensed and provide for product-specific conditions. ^{[8] [9]} Procurement should therefore ask for operational definitions and permitted uses, alongside the technical export schema.

Key Changes: From a Code List to an Edition-Aware Record

Record the source edition before interpreting the value

The important change is in the data contract, not a claim that this report announces a new IATA standard. Keep the reported scheme and edition with each imported record. IATA's dated 2026 update and its advertised 2027 changes are separate source statements. ^{[1] [2]} An integration should not infer either edition from the retrieval date of a public web page.

The Portal's legacy table is useful for orientation, but its reference to AHM730 and the 2012 manual limits what it verifies. (Source: ansperformance.eu) For production mapping, obtain the operator's licensed dictionary, the supplier's implementation declaration and applicable local-code policy. Where an edition is supplied only at feed level, preserve the dated supplier declaration and its scope, then associate it with the affected records. Mark an edition inferred from that declaration as inferred.

The proposed fields are:

• Source value: retain the original characters and any subcode.
• Coding scheme: distinguish IATA, airline-local and supplier-local namespaces.
• Edition: retain the declared edition or an explicit unknown state.
• Source actor: identify the reporting organisation and role.
• Mapping version: identify the approved transformation used downstream.

These fields describe the proposed contract. Separating contract version from content version has a general precedent in OpenAPI, which distinguishes the document's version from other specification and application programming interface (API) versions. ^[10]

Preserve representation and information layers

The published AODF specification supports numeric and alphabetic representations, optional subcodes and multiple cause-duration pairs. (Source: www.eurocontrol.int) Its published structure has DLY1 to DLY5 and TIME1 to TIME5, with durations in integer minutes. (Source: www.eurocontrol.int) These slots describe the published interface, not a universal limit on an internal analytical model. A source string should consequently be retained before normalization. Stripping leading characters, dropping suffixes or converting unknown values to a familiar label can remove information needed to reconstruct the import.

AHM732 needs particular care. EUROCONTROL describes its Process, Reason and Stakeholder structure and notes that the described demonstration used the Process layer for a dashboard. (Source: www.eurocontrol.int) A displayed process group is therefore not evidence that every reason or stakeholder component has survived an export. IATA's advertised 2027 changes also mention revisions to the AHM732 process matrix and related movement-message provisions. ^[11]

Ask which layers the supplier sends, which fields remain local, and which labels are derived. A mapping between schemes should describe any lost granularity. A transformation approved for a dashboard need not be approved for detailed performance investigations.

Treat revisions as new analytical inputs

A corrected allocation can alter cause shares without changing total departure delay. Retaining only the latest total hides that distinction. PROV-O defines a revision as a derivation into a revised version, providing a useful conceptual link between original and corrected entities. ^[12]

The proposed revision record should retain:

• Original allocation: the earlier cause entries and durations.
• Replacement allocation: the newly submitted entries.
• Revision identity: an explicit link to the superseded record.
• Revision actor: the person, role or system submitting the change.
• Revision reason: the explanation and evidence reference.
• Decision state: accepted, disputed or awaiting review.

Store supplier revision time and integration receipt time separately. Request for Comments (RFC) 3339 defines explicit numeric time offsets, making it suitable for exchanging timestamps without an implicit local timezone. ^[13] Timestamp format still does not decide which conflicting revision is authoritative; that remains a documented business rule.

Implementation Considerations and Process Changes

Identify the flight leg and retain the original payload

The proposed leg key must distinguish operational dates, legs and suppliers. Define it using the operator's authoritative records, retaining each source identifier. A universally unique identifier (UUID) can identify a stored record, but its identifier mechanics do not resolve whether two payloads describe the same real-world leg. ^[14]

The event identifier is separate again. CloudEvents defines uniqueness using source plus id, and permits consumers to treat repeated combinations as duplicate events. ^{[15] [16]} Under the proposed adapter policy, a retransmission should not create additional cause minutes; a genuine correction should have an explicit revision relationship. Do not silently equate identical flight numbers with duplicate submissions.

Retain the original supplier payload or a governed reference to it, including content needed to replay the approved import. Preserve provenance between the source record and the derived analytical record. PROV-O supplies entity, activity and agent concepts for such relationships. ^[6] The proposed checksum should complement accessible source evidence.

Keep event timestamps separate from attribution

Out-Off-On-In (OOOI) denotes gate out, wheels off, wheels on and gate in in the Federal Aviation Administration (FAA) reference. ^[17] These timestamps help define the interval being measured. The FAA also documents estimated values when OOOI observations are unavailable. ^[18] The contract should carry observation status and source, rather than treating an estimate as equivalent to an observed event.

Airport Collaborative Decision Making (A-CDM) provides the adjacent milestone context. EUROCONTROL describes linking inbound and outbound flights and updating downstream estimates from milestones. (Source: www.eurocontrol.int) Dublin Airport describes partner data exchange involving airport and operational stakeholders. ^[19] Such links can identify candidate evidence for an upstream rotation relationship; they do not establish the delay allocation by themselves.

Table 1 sets out the proposed record contract. The source column identifies supporting concepts, not a claim that each cited document mandates the complete row.

The contract makes transformations inspectable. A reviewer should be able to select a displayed cause total and recover the supplier value, applied dictionary and accepted revision. Implementations may use another technical vocabulary, provided they preserve the same evidence relationships and can export them.

Mapping Governance, Unknowns and Review Ownership

Govern mappings as a separate asset

A mapping registry should record the source namespace, applicable edition, target definition, transformation rationale and approving owner. Its version belongs on each derived record. Changes in serialization, dictionary edition and mapping logic are different events; combining them into an undifferentiated version obscures what changed. OpenAPI's separation of version concepts is a useful reference for the contract design. ^[10]

Recommended mapping controls are:

• Scope: declare supplier, stations, reporting use and applicable editions.
• Effective period: define when the mapping is valid for source records.
• Transformation: document direct equivalence, grouping or information loss.
• Evidence: link the authorized definition and approval record.
• Owner: name the operator role accountable for accepting the mapping.
• Release: test a changed mapping against saved representative payloads.
• Reprocessing: preserve the original result when rebuilding historical views.

CloudEvents recommends different schema references for incompatible changes. ^[22] Apply the same general discipline to the adapter contract, while retaining an independent code-edition field. A technically compatible payload can still contain an unfamiliar code dictionary.

Do not turn unknown into other

Missing, unrecognized, unmapped and disputed are proposed data-quality states with different remediation paths. Missing means no value arrived. Unrecognized means the value could not be identified within the declared scheme. Unmapped means it is recognized but has no approved target transformation. Disputed means competing submissions or evidence require a decision.

JSON Schema explicitly distinguishes null from an absent value. ^[21] Its object documentation also explains that required fields must be declared. ^[20] An adapter should therefore validate both presence and meaning. A duration of zero is a submitted numerical value; a missing duration is not a zero-minute cause.

An operator-local code should remain in its local namespace until its owner approves a mapping. Bytron's public explainer explicitly describes configuring codes to internal standards, illustrating why a local registry is a normal integration consideration. (Source: www.bytron.aero) Do not assume that a matching short code across suppliers establishes semantic equivalence. An unknown edition should constrain confidence in a proposed mapping, even when the characters look familiar.

Assign the review to the right owner

Station teams should resolve source payload questions; the performance owner should approve attribution and reporting policy; integration staff should own implementation reproducibility. Dublin Airport's description of A-CDM information exchange illustrates the multi-party operational setting, rather than establishing a universal allocation authority. ^[19]

The review queue should expose:

• Original value: what arrived before normalization.
• Affected leg: canonical identity and unresolved matches.
• Missing context: edition, duration, actor or evidence access.
• Candidate mapping: proposed target with approval status.
• Revision conflict: competing allocations and their source times.
• Assigned owner: the role needed to resolve the specific issue.

IATA's public website terms and store conditions also require attention to permitted use. ^{[23] [8]} A public reference is not blanket permission to redistribute a licensed dictionary. Obtain permission and product-specific terms before embedding definitions in supplier-facing exports or a shared service. ^[9]

Native Platforms Versus a Narrow Integration

Test the existing workflow first

The report's purchasing recommendation is native configuration first. Bytron's skybook FAQ describes admin edits to signed-off sector reports, including delay information, and records an audit trail with timestamps, user details and an edit reason. (Source: www.bytron.aero) It also describes integration or export of post-flight data. (Source: www.bytron.aero) These are relevant documented capabilities, but acceptance still requires examining the operator's actual export and configuration.

A demonstration should follow an original record through correction and reporting. Ask whether the exported history retains the earlier cause-minute allocation, the source actor, revision time, source dictionary and mapping release. An audit trail visible in a user interface may answer a different question from an exported analytical record. Public documentation alone does not settle the operator's licensed configuration.

Event feeds need a similarly specific test. OAG documents a Flight Info API flight-instances JSON endpoint, while SITA describes real-time and historical flight information APIs. ^[24] (Source: www.sita.aero) Their documented existence does not establish that the purchased feed includes the operator's reported cause minutes and revision chain. Specify those fields in the procurement question, instead of treating status data and attributed causes as interchangeable.

Table 2 compares decision routes. LANDING.AERO appears as a custom-build option because the decision includes commissioned integration, not because it sells a packaged delay-code platform.

The routes are complementary. A feed can supply event context, a native platform can hold approved attribution, and an adapter can bridge a demonstrated mismatch. The decision should turn on a failed acceptance criterion and its remedy, rather than on a general preference for custom software.

Keep the adapter scope measurable

A narrow scope should specify:

• Inputs: named suppliers and source contract versions.
• Outputs: explicit analytical fields and export format.
• Permissions: dictionary use and source-evidence access.
• Exceptions: review states and their accountable owners.
• Replay: reconstruction of prior approved outputs.
• Handover: ownership of mappings, tests and documentation.

Schema validation is necessary but insufficient. OpenAPI documents that format can be a non-validating annotation, so timestamp validation must be tested in the selected implementation. ^[25] A valid payload can still have the wrong leg, unknown edition or disputed allocation. The acceptance workflow must test those semantic conditions separately.

Data Analysis and Evidence

Keep the denominator and reporting rules visible

EUROCONTROL's 2024 CODA publication reports 17.5 minutes per flight, against 17.6 in 2023, and 8.0 minutes per flight of reactionary delay. (Source: www.eurocontrol.int) (Source: www.eurocontrol.int) Its report separately gives 15.5 minutes per flight of arrival delay and 34.2 minutes per delayed flight of departure delay, with the latter population using a five-minute threshold. (Source: www.eurocontrol.int) These measures and denominators do not benchmark supplier mapping quality.

For US reporting, Title 14 of the Code of Federal Regulations (CFR), section 234.4 uses the designated computerized reservation system (CRS) schedule baseline and specifies reporting for arrival delays of 15 minutes or more, with causal components of five minutes or more. ^{[26] [27]} BTS's Technical Directive 40, effective 1 January 2026, requires arrival-delay reconciliation, assigns additional arrival delay to the National Aviation System and describes prorating time savings. ^[4] AODF instead uses a departure-oriented inequality.

Resolve this source distinction before implementation: the regulation requires each qualifying component; the directive discusses consistent predominant-cause reporting. ^{[27] [4]} Confirm the reporting owner's applicable policy. The Department of Transportation describes reporting directives as clarifications of regulations. ^[28] This report supplies no universal IATA-to-BTS crosswalk or filing instruction.

Cause minutes and residuals (Hypothetical Example)

All quantities are synthetic. The proposed departure measure is the nonnegative actual-off-block minus scheduled-departure interval. Assume 40 minutes of delay and allocations of 18, 12 and 5 minutes. Allocated minutes are 18 + 12 + 5 = 35; the unallocated residual is 40 minus 35 = 5 minutes. AODF permits a lower allocated total. (Source: www.eurocontrol.int)

A corrected allocation of 22, 8 and 5 minutes still totals 35. Delay and residual remain unchanged; the first cause gains four minutes, the second loses four. Preserve both allocations and their revision link, consistent with PROV-O. ^[12] This illustrates arithmetic, not allocation policy.

Table 3 provides synthetic acceptance cases. Inputs represent neither a current licensed dictionary nor an industry sample.

Syntax validity does not approve a mapping; a balanced total does not establish root cause. Failed pairings and disputed revisions should remain visible in exports and aggregates.

Unresolved-record share (Hypothetical Example)

Assume 12 unresolved cause records among 200 imported cause records, synthetic. The unresolved share is 12 / 200 = 6%. The denominator is cause records. Report missing-duration, unknown-edition and disputed-revision counts separately. No industry target is inferred.

Report measurable unresolved minutes separately. Missing minutes require a count, not an invented duration; preserve that distinction using JSON Schema's null and absence mechanics. ^[21] Compare mapping releases against the same retained population.

Implications and Future Directions

Traceable classifications are reusable analytical assets

EUROCONTROL's data page links the Portal code reference when explaining grouped analysis. (Source: www.eurocontrol.int) That is documented institutional use within the same resource family, rather than independent endorsement of a current licensed dictionary. A Council-hosted Commission non-paper dated 11 March 2026 reuses CODA classifications and identifies uncertainty around unknown and differently aggregated cancellation categories. (Source: data.consilium.europa.eu) It is an analytical working document, not a newly enacted coding requirement.

The implication is narrow: classifications travel between analyses, so the edition, grouping rule and unresolved population should travel with them. Keep cancellation and delay taxonomies separate unless an explicitly documented reporting transformation connects them. BTS itself cautions that airlines do not report the underlying causes of late-arriving aircraft. ^[29] Rotation labels can therefore leave a real evidentiary gap even when the submitted category is valid.

Automation should preserve review and evidence

EUROCONTROL describes a validation-stage demonstration suggesting Process and Reason codes from text or voice. (Source: www.eurocontrol.int) That is evidence of a described approach, not a public independent accuracy benchmark. A suggested classification should remain distinguishable from an operator-accepted allocation, with retained input, suggestion version and review outcome in the proposed design.

Before supplying licensed code definitions or other IATA information to a generative-AI system, confirm that the applicable agreement or written permission from IATA permits that use. IATA's Store Conditions of Sale, section 4(i) and Website Terms of Use, section 3 restrict such use, including analysis and derivative uses. Keep this contractual check separate from reviewing suggestions based on operator-owned incident narratives; do not infer IATA reuse rights from EUROCONTROL's demonstration.

Useful future acceptance questions include:

• Edition transition: can old and new dictionaries coexist without rewriting history?
• Source replay: can a prior output be reconstructed from retained evidence?
• Revision export: can another system recover both approved and earlier allocations?
• Unknown recovery: can a newly approved mapping resolve historical records transparently?
• Automated suggestions: can reviewers identify and correct machine-proposed values?

A common event envelope can assist interoperability, but the airline-specific contract remains necessary. CloudEvents defines a common description of event data; it does not define delay semantics. ^[7] Incompatible contract changes should receive explicit schema identifiers, while code-edition transitions retain their own field. ^[22] The useful long-term asset is a governed mapping and evidence chain that remains inspectable when suppliers, schemas or reporting purposes change.

Conclusion

IATA delay codes become dependable analytical inputs when an operations system preserves what was reported, under which coding scheme and edition, with which durations, and through which revisions. The public references show why those distinctions matter: the Portal points to an older manual, IATA publishes edition-specific changes, and AODF accepts paired cause allocations. (Source: ansperformance.eu) ^[11] (Source: www.eurocontrol.int) Those facts support an edition-aware acceptance contract, not an assumption that every familiar code has identical meaning across suppliers.

The immediate decision is to inspect the native workflow and its actual export. Require a representative record with multiple causes, an explicit unknown, a local code and a subsequent revision. Recover the original payload, mapping release and evidence references from the resulting report. Where that succeeds, retain the native route. Where a specific exchange requirement fails, define the smallest integration that closes the gap, with clear ownership and permissions.

Keep three judgments separate throughout: whether a record passes structural validation, whether its mapping and allocation are approved, and whether the available evidence explains the disruption. An unallocated residual or disputed revision is useful information. Preserving it enables review; replacing it with a convenient category weakens the analytical record.

The objective is reproducibility: a performance manager should be able to understand both the current result and how it changed. Source editions, cause-minute pairs, versioned mappings and explicit unresolved states make that possible without turning a reporting label into a causal or legal conclusion.