A-CDM TOBT TSAT Integration: An Airline OCC Event Contract

Executive Summary

A-CDM TOBT TSAT integration should connect an airline's operations control centre (OCC) to authoritative airport and network information while retaining the origin, revision and meaning of each value. Airport collaborative decision-making (A-CDM) is a partnership process: Berlin's airport explicitly describes it as a concept rather than a purchasable product. ^[1] The relevant European baseline is EUROCONTROL's edition 1.0 specification, published 30 January 2025; the International Air Transport Association (IATA) also links a June 2025 toolkit from its operational-concepts guidance. (Source: www.eurocontrol.int) ^[2] Neither reference alone establishes an airport subscription entitlement.

Target off-block time (TOBT) represents anticipated aircraft readiness. Target start-up approval time (TSAT) reflects departure sequencing and constraints. Berlin's explanation connects TOBT changes to ground handling and TSAT calculation to local runway and network capacity. ^{[3] [4]} An OCC should receive both without treating them as interchangeable commitments. At Nice, the published Aeronautical Information Publication (AIP) assigns TOBT updates to handlers, flight-plan and estimated off-block time (EOBT) updates to airlines, and TSAT and target take-off time (TTOT) calculation to the airport operator. ^{[5] [6] [7]} Its 1 October 2026 effective publication provides a concrete local ownership model, rather than permission for an arbitrary OCC application to write those fields. ^[8]

The proposed contract retains accepted values and their history, separates predicted from actual events, and records occurred, received and effective times. CloudEvents offers general event semantics; AsyncAPI can describe message-driven interfaces. These are optional engineering choices, not airport mandates. ^{[9] [10]} Access must be established independently: Berlin requires a user agreement. ^[11] A usable application programming interface (API) still needs deployment-specific field and write rights. Local TSAT distribution and Network Manager message triggers are separate requirements. (Source: www.eurocontrol.int)

The practical decision is whether the existing airport or handler platform already supplies the required information, permissions and reconciliation workflow. If it does, configuration and controlled use may suffice. A custom adapter becomes useful when authorised feeds must enter an existing turnaround or roster system with auditable revision handling. Original A-CDM evidence addresses a broader intervention: EUROCONTROL's historical assessment used 17 fully implemented airports, rather than benchmarking an OCC adapter. (Source: www.eurocontrol.int) Procurement should therefore test freshness, duplicates, withdrawals and conflicting sources against a signed interface agreement, and measure adapter outcomes separately from whole-airport benefits.

Introduction and Background

An airline OCC needs a coherent operational picture, but coherence does not mean storing every departure-related timestamp in one mutable field. A handler's readiness forecast, an airport's sequencing output and a network allocation answer different questions. The German A-CDM Harmonisation Group explicitly treats EOBT and TOBT separately and restricts TOBT changes to the locally responsible person. ^[12] For integration architects, that separation is the starting requirement: preserve semantics before automating reconciliation.

This report examines European A-CDM and selected airport implementations as of October 2026. It concerns information exchange, permissions and discrepancy review, with local approved procedures governing operational action. EUROCONTROL distinguishes full A-CDM from Advanced ATC Tower, which shares a smaller subset of information with the network. A connected airport label therefore cannot be used as a substitute for a field-level inventory. (Source: www.eurocontrol.int) Berlin directs business partners to the AIP for further information, reinforcing the need to identify the local procedure alongside the general concept. ^[13]

The architectural question is how airport A-CDM data for airline OCC enters systems already used for turnaround progress, aircraft rotations and crew planning. Predictions may inform those systems without acquiring the authority to change a published airport value. Schiphol's Deep Turnaround page illustrates this distinction: it describes predictions that help handlers set TOBTs and an API for its product data. It does not establish a general TOBT-writing entitlement. (Source: www.schiphol.nl) (Source: www.schiphol.nl)

Custom development is a relevant procurement category when the work concerns integration. LANDING.AERO describes applications designed around operational needs, including integration of disparate data sources. These statements establish its build-to-order model, not an existing airport connector or a certified operational service. (Source: www.landing.aero) (Source: www.landing.aero) The following analysis compares the scope of an adapter with existing platforms without assuming that custom software is required. The acceptance decision should depend on verified access, source ownership and a testable interface contract.

Key Changes for OCC Integration

The changes below are proposed changes to an operator's information architecture. They are not a claim that every concept was newly introduced by the current specification.

Separate readiness, sequencing and flight-plan ownership

TOBT and TSAT difference is primarily a difference in meaning and authority. Berlin associates TOBT maintenance with changes in handling; its TSAT explanation considers runway and network capacity. ^{[3] [4]} An OCC can show these values together, but should label the handler's readiness forecast and the airport's sequencing result separately. A late arrival prediction belongs in the supporting evidence, rather than silently replacing either accepted value.

EUROCONTROL's specification assigns TOBT responsibility to the aircraft operator, allowing delegation to the ground handler; §5.1.9.3 distributes every changed TSAT locally and specifies a target departure planning information (T-DPI) update when recalculated TTOT changes by at least 5 minutes. (Source: www.eurocontrol.int) These are separate responsibilities and distribution rules. An operator adapter should retain each authorised local update it receives, even when its own user interface suppresses repetitive notifications. Its display policy should not impersonate the network-message policy.

Separate a proposal from an accepted revision

A turnaround model may suggest a revised readiness time. Frankfurt's published description says an automatically generated TOBT never overwrites a manually set TOBT. ^[14] IATA's toolkit similarly prioritises manual airline or delegated-handler updates over preliminary predictive off-block estimates. ^[15] Together these sources support a contract that records proposed, submitted, accepted, rejected and withdrawn states explicitly.

The operator's internal forecast can remain visible when it disagrees with the airport value. The discrepancy should have an owner and a reason, such as an unfinished handling task or an awaiting acknowledgement. Saving a request does not prove that the airport accepted it. Frankfurt publishes a separate transfer document for TOBT responsibility and viewing rights, which is further evidence that authority and visibility are distinct concerns. ^[16]

Separate local updates from network propagation

Frankfurt describes departure planning information (DPI) flowing from airport to network, with flight update messages (FUM) flowing in the other direction. ^[17] EUROCONTROL's DPI publication describes the available message family; the FUM publication addresses airports, air navigation service providers (ANSPs) and software developers. (Source: www.eurocontrol.int) (Source: www.eurocontrol.int) These interfaces should not be represented as a single undifferentiated airport event bus.

Migration note: Distinguish the DPI/FUM information from its legacy transport. EUROCONTROL's published DPI & API Implementation Roadmap (edition 2.400, §4.3.2) identifies 31 December 2025 for DPI/FUM exchange via SWIM by NM, ANSPs and the specified set of airports within CP1 scope. It gives 31 December 2027 as the target sunset for legacy DPI/FUM messaging for all airports, including those outside CP1, and ANSPs. ( EUROCONTROL roadmap The FUM guide describes receiving equivalent information through an NM B2B FlightDataMessage subscription. ( EUROCONTROL FUM guide, Appendix A For an October 2026 integration, require the provider to confirm its current NM B2B/SWIM service, subscription coverage and migration plan; the published dates alone do not establish deployment status. Document OCC eligibility and access separately: NM B2B access is subject to eligibility and usage conditions. ( EUROCONTROL NM B2B access Do not treat this airport/network migration as an OCC access grant or a requirement to adopt the proposed internal event envelope.

EOBT reconciliation also requires a named mechanism. EUROCONTROL's EOBT update service allows operators to delegate delay-message (DLA) filing at designated airports. (Source: www.eurocontrol.int) That is a particular service arrangement, not an automatic consequence of receiving TOBT. Record whether the operator, its dispatch system or an authorised service sends flight-plan changes. Prevent parallel writers from assuming the other has already acted.

Authority and the Event Revision Record

Table 1 proposes a source-of-truth and revision matrix. Its exception owners and retained metadata are design recommendations; the cited sources establish the underlying ownership or message context. Consumer entries describe the intended OCC integration, not a public access grant.

The table's main implication is that authority attaches to a field and workflow, not to the newest message. An airport may aggregate information from several actors, but an aggregation endpoint should not erase the underlying origin. Berlin limits its extranet visibility to flights for which the user is responsible, illustrating why both the flight scope and actor role belong in the contract. ^[21]

The event record should include the following proposed elements. CloudEvents defines source context, occurrence time and additional context attributes, which can provide a compatible envelope if both parties choose it. ^{[22] [23] [24]}

• Flight identity: airport flight identifier, operating carrier reference, operating date and available rotation correlation, with explicit rules for substitutions and diversions.
• Value semantics: field name, forecast or actual classification, status and units; never infer observation from the field name alone.
• Origin and publisher: the actor that supplied the value and the platform that delivered it, with the authorised role when available.
• Event identity: publisher-scoped identifier and source key, retained across delivery retries.
• Revision: a source sequence or version where supplied; otherwise an explicitly limited adapter revision that does not pretend to be airport ordering.
• Time axes: target value, occurrence time, publication time, receipt time and any effective interval, with unknown times represented honestly.
• Causality: superseded event, request acknowledgement and correlation references, rather than a guessed relationship based on arrival order.
• Evidence and access: source-document revision, transformation version, permission scope and the raw message retained within agreed use rights.

EUROCONTROL's recording requirements specify recording, timestamping and archiving exchanged data. (Source: www.eurocontrol.int) The operator should separately agree its own retention scope and duration. There is no basis here for assigning a universal retention period. When archived messages can be replayed, also retain the mapping version used to produce the OCC projection; otherwise historical views may change when an adapter is upgraded. Semantic Versioning requires changed released contents to be issued as a new version, a useful discipline for published mapping contracts. ^[25]

Airport Access and Local Procedure Matrix

Table 2 distinguishes verified public documentation from questions still requiring bilateral answers. The rows are examples of access discovery, not a directory of interchangeable A-CDM APIs.

The matrix shows that portal availability, data subscription and write authority are different findings. Zurich's stakeholder page calls for transparent cooperation. That statement does not supply an interface contract. (Source: www.flughafen-zuerich.ch) A procurement dossier should preserve both confirmed rights and unresolved questions rather than translating a general collaboration statement into presumed technical access.

For each value, obtain written answers to these access questions:

• Coverage: which airports, airline identifiers, handler relationships and flight dates are visible?
• Delivery: is the agreed channel a portal, query API, pushed message feed or another supported mechanism?
• Ownership: who supplies the value, who may submit a change, and who confirms acceptance?
• History: are revisions, withdrawals, snapshots and recovery requests available?
• Use rights: may the operator store raw messages, reconcile them with crew data and distribute derived displays internally?
• Continuity: who handles credential renewal, planned changes and interface outages?
• Support: who owns payload defects, missed updates and source-value discrepancies?
• Procedure version: which current local document governs the integration's interpretation?

System-wide information management (SWIM) does not remove these questions. SESAR describes SWIM as interoperability and standardisation rather than a single technology, and identifies its registry as a way to improve information-service visibility. (Source: www.sesarju.eu) (Source: www.sesarju.eu) Finding a service is therefore the beginning of access assessment, not its conclusion.

Implementation Considerations and Process Changes

A-CDM API integration should start with the existing airport and handler workflow. Berlin's AOE and Frankfurt's CSA Tool already provide documented TOBT-related access paths. ^{[21] [27]} The operator should first test whether those paths, or another authorised existing integration, meet its operational information needs. A new adapter should solve a demonstrable gap in delivery, reconciliation or presentation.

Aviation Information Data Exchange (AIDX) is IATA's Extensible Markup Language (XML) messaging standard for flight-data exchange. ^[30] The older IATA recommendations identify it as a candidate format; the implementation guide leaves transport mechanisms unspecified and recommends bilateral agreements covering exceptions, retry logic and resynchronisation. ^{[31] [32]} Consequently, a payload choice does not define authentication, subscription, replay or TOBT permissions. Describe the licensed standard by reference and build an operator-specific mapping without reproducing its schema.

AsyncAPI can document message definitions, channels, connection details and correlation identifiers. ^{[33] [34] [35]} Use those capabilities to specify a contract that a receiving system can test. Keep the application's API version distinct from the documentation specification version, as AsyncAPI itself does. ^[36] Semantic Versioning additionally requires an explicit public API; adopting its terminology is useful only when compatibility has been defined for the actual fields and behaviours. ^[37]

Table 3 compares delivery approaches. LANDING.AERO appears because custom integration is a procurement category within this report; its documented model is build-to-order rather than an off-the-shelf A-CDM platform.

The comparison is about scope, not a ranking of suppliers. Frequentis describes a shared operational picture connecting airport stakeholders; Amadeus documents incorporating additional data through APIs. ^{[41] [39]} Neither description substitutes for a deployment-specific field list. Conversely, custom software cannot create access rights that an airport or handler has not granted.

Choose an adapter when the evidence demonstrates these needs:

• Multiple authorised sources: accepted airport values, internal readiness forecasts and network information must remain distinguishable in one interface.
• Workflow fit: existing staff need discrepancies presented within the turnaround or roster application they already use.
• Revision retention: the existing integration cannot reconstruct accepted, withdrawn and superseded values adequately.
• Reconciliation control: the operator needs explicit source precedence and acknowledgement tracking across systems.
• Recovery: the current connection lacks a tested way to restore the OCC view after interrupted delivery.
• Ownership: named data and application owners can maintain mappings, rights and local procedure changes.

Use a packaged or existing platform when it already satisfies those requirements with a supported agreement. SWIM's semantic interoperability model can help structure the vocabulary, while still leaving the actual service and ownership arrangements to be confirmed. (Source: www.sesarju.eu)

Subscriptions, Reconciliation and Acceptance Tests

An A-CDM event data contract should define both the event stream and the state that the stream reconstructs. AsyncAPI operations identify the channels they use, while CloudEvents identifies duplicate events through the combination of source and identifier. ^{[42] [43]} These are useful patterns for specifying subscriptions and retries without assuming that airports implement either standard.

Receive TOBT changes and withdrawals, TSAT publications and withdrawals when available, accepted EOBT modifications, CTOT revisions, TTOT updates and movement actuals within the authorised scope. Agree a snapshot or equivalent recovery mechanism. A subscription that starts midway through a turnaround needs a known baseline before the receiving system can interpret later events. Where the airport offers only polling, document how the adapter distinguishes an observed value change from an event it never received.

The proposed reconciliation policy should answer:

• Duplicate handling: retain delivery evidence while applying the same source event only once to operational state. ^[43]
• Ordering: use the provider's revision semantics where available; receipt time alone must not determine source precedence.
• Unknown chronology: mark uncertainty explicitly when neither revision nor trustworthy occurrence time is available.
• Replacement: link a correction to the event it supersedes; keep the replaced estimate available for review.
• Withdrawal: clear the current authority of a revoked estimate without treating an absent value as a completed movement.

Cancellation semantics require particular care. EUROCONTROL's C-DPI invalidates previously supplied planning information when a replacement estimate is unknown; it should not automatically cancel the airline's commercial flight record. (Source: www.eurocontrol.int) Frankfurt's local description separately requires an unachievable TOBT to be updated or deleted. ^[44] The contract should distinguish withdrawal of an estimate, cancellation of a network planning message and cancellation of the flight itself.

Time handling also belongs in acceptance criteria. Request for Comments (RFC) 3339 defines an Internet timestamp profile and explicit numeric-offset semantics; the World Wide Web Consortium (W3C) XML Schema's dateTimeStamp requires a timezone offset. ^{[45] [46] [47]} Store complete dates and offsets, normalise comparisons to Coordinated Universal Time (UTC), and make local display conversion a separate presentation step. RFC 3339 explicitly discusses converting UTC to local time for display. ^[48] A local clock label without its date and zone should never silently become a canonical instant.

Run these acceptance scenarios with agreed test messages:

• Late accepted revision: a newer source revision arrives before an older one; the current projection retains the authoritative newer state.
• Duplicate delivery: the same source event is delivered again after reconnect; delivery history grows but the business transition is not repeated. ^[43]
• Revoked TOBT: an accepted estimate is withdrawn; the prior value remains historical and the current display indicates withdrawal.
• Conflicting proposal: an internal model predicts a different readiness time; the accepted manual value stays intact pending authorised action. ^[14]
• Rejected write: a submitted change lacks acceptance; the OCC displays the request status without replacing the airport value.
• Midnight and zone change: date-bearing UTC values compare correctly while the local display changes. ^{[49] [48]}
• Recovery gap: delivery resumes with a snapshot whose revision cannot be reconciled; the adapter raises an owned discrepancy rather than inventing intervening events.
• Contract change: an incompatible payload is quarantined or handled by an explicit new mapping; CloudEvents recommends a different schema URI for incompatible changes. ^[50]

For TOBT TSAT data quality, success means that an authorised consumer can determine which value is current, what it means, where it came from and what remains uncertain. The release dossier should include the verified procedure version, permission record and the results of these scenarios, not merely an endpoint that returns timestamps.

Data Analysis and Evidence

The available numbers answer different questions. EUROCONTROL's concept page reported 34 fully implemented European A-CDM airports when accessed for this report. (Source: www.eurocontrol.int) Its assessment published 18 April 2016 drew on 17 airports and reported over 34% of European Civil Aviation Conference departures originating at CDM airports at that historical point. (Source: www.eurocontrol.int) (Source: www.eurocontrol.int) The percentage and airport count are different measures with different dates; they should not be combined into a growth rate or coverage estimate.

That historical publication describes reductions in taxi time, fuel burn and flow-management delay, among other whole-airport benefits. (Source: www.eurocontrol.int) The Civil Air Navigation Services Organisation (CANSO) likewise frames integration around operational use cases and supporting collaborative procedures. ^{[51] [52]} These sources establish why information exchange matters, but they provide no verified performance forecast for the proposed OCC adapter. The original historical PDF could not be retrieved during this research; detailed numerical benefit claims from that PDF are therefore excluded.

Documented timing rules also have distinct purposes. EUROCONTROL §7.4 includes 1-minute provision defaults, 5-minute target-time changes and 3-minute taxi-time changes for specified network information requirements. These are not proposed OCC alert thresholds. (Source: www.eurocontrol.int) Heathrow's page states local EOBT alignment within plus or minus 10 minutes of TOBT; the German harmonisation FAQ describes an opt-in automatic update criterion capped at 15 minutes. ^{[53] [54]} Encode the applicable rule with its source, configuration and boundary condition rather than choosing a convenient common number.

Even update-count rules vary by document. The German FAQ specifies a maximum of three TOBT updates after TSAT issue; Copenhagen's published 2018 guide permits further updates while recommending restraint. The latter is historical evidence, not confirmation of a current procedure. ^[55] (Source: www.cph.dk) This discrepancy is sufficient reason to avoid one airport-independent counter.

An operator's own evaluation should measure the following proposed indicators, using an agreed observation window and reporting missing data:

• Delivery lag: receipt time minus source publication time, with distributions and clock-quality qualifications.
• State completeness: proportion of relevant authorised flights with a current value, explicit withdrawal or explained absence.
• Reconciliation workload: discrepancies opened, resolved and still outstanding, grouped by source and cause.
• Recovery quality: events or state changes that cannot be reconstructed after an interruption, plus time to restore a trusted projection.

CloudEvents occurrence time supports event chronology, while AsyncAPI correlation identifiers support tracing. Neither by itself guarantees synchronised clocks or delivery performance. ^{[23] [35]} Quantitative acceptance targets should be negotiated from the actual interfaces and workflow needs. Measure packaged-platform configuration and a custom adapter against the same definitions before comparing outcomes.

Case Studies and Real-World Examples

TOBT, TSAT and EOBT reconciliation (Hypothetical Example)

All values in this example are invented for arithmetic and event-state testing. They are not airport thresholds, observed flight performance or instructions for requesting start-up. Assume the authoritative airport snapshot contains TOBT 14:00 UTC, TSAT 14:08 UTC and TTOT 14:23 UTC. The operator's accepted flight-plan view contains EOBT 13:55 UTC. Subtraction gives an 8-minute TSAT-to-TOBT interval, a 15-minute TTOT-to-TSAT interval and a 5-minute TOBT-to-EOBT difference. None of these differences alone identifies who should modify a value.

Now suppose a handler publishes accepted TOBT revision B at 14:02 UTC, changing the target to 14:06 UTC. Its delivery reaches the OCC at 14:03 UTC. The airport then publishes TSAT 14:12 UTC and TTOT 14:27 UTC. A delayed delivery of revision A reaches the OCC afterwards. The source revision, not arrival order, keeps revision B current. The contract records both deliveries and their ordering basis. CloudEvents duplicate identifiers can help deduplicate retries, but do not replace an agreed business revision sequence. ^{[43] [22]}

The new hypothetical TOBT-to-EOBT difference is 11 minutes. Whether an EOBT amendment is required depends on the applicable local procedure and configured update service. EUROCONTROL's service, for example, does not automatically advance EOBT when TOBT is earlier. That documented service behaviour shows why a universal equation such as “EOBT equals TOBT” is inappropriate. (Source: www.eurocontrol.int) The OCC should present the discrepancy and identify the authorised flight-plan owner rather than submitting competing amendments by default. Nice's AIP explicitly places EOBT maintenance with airlines. ^[6]

For a hypothetical local display offset of UTC plus 2 hours, TOBT 14:06 UTC displays as 16:06 on the same date. Canonical comparisons still use the date-bearing instant. RFC 3339 defines offset arithmetic and permits local display conversion. ^{[46] [48]} The display offset in this example is invented, not a statement about a particular airport or daylight-saving rule.

Finally, suppose revision B is withdrawn without a replacement. The interface preserves B as history and labels current readiness unknown. Frankfurt's documented TOBT update-or-delete behaviour supplies a real reason to test this state transition. ^[44] A later internal prediction may be shown as a proposal, but it does not restore an accepted airport estimate. The exercise passes when users can explain the source, acceptance status and chronology of every displayed value.

Implications and Future Directions

The most useful progression is from collecting more timestamps to documenting stronger information relationships. IATA currently links its comprehensive toolkit, while its AIDX page distinguishes schema releases from implementation-guide updates. ^{[2] [56]} An integration review should therefore track the airport procedure, payload contract and adapter mapping separately. A document with a newer date does not automatically redefine a locally authorised workflow.

Forecasting and AI-assisted workflows may improve an operator's internal estimate or highlight a discrepancy. Schiphol documents predictive information that helps handlers set TOBT, which is a concrete example of forecasts supporting a responsible actor. (Source: www.schiphol.nl) The appropriate integration pattern retains that distinction: store the model output, supporting evidence and model revision, then record any authorised human or system submission and airport acceptance separately. Avoid assigning a model the authority of the airport sequencer merely because its timestamp appears more recent.

Machine-readable contracts can make responsibilities easier to review. AsyncAPI is architecture-agnostic, and CloudEvents offers a common description of event data; neither requires a specific airport technology stack. ^{[57] [9]} Compatibility can be managed with an explicit API and documented breaking changes, following Semantic Versioning where suitable. ^{[37] [58]} The future benefit is testable interpretation across systems, rather than a promise that all airports will expose a single interface.

For procurement, require the delivery partner to demonstrate access, source mapping and recovery against the actual airport agreements. Brussels' separate app and developer-portal documentation illustrates why a general digital presence is insufficient evidence for the desired feed. (Source: www.brusselsairport.be) (Source: developer.brusselsairport.be) A working demonstration should include withdrawals and conflicting inputs, and should show how the operator can inspect the underlying evidence. These requirements apply equally to an existing platform and custom development.

Frequently Asked Questions (FAQs)

Which airport A-CDM data should an airline OCC receive?

Receive authorised readiness, sequencing, flight-plan, network-allocation and movement information required by the operator's workflow. Preserve provenance and status. Frankfurt documents distinct airport-to-network DPI and network-to-airport FUM directions, so neither should be treated as a generic replacement for all local values. ^[17]

Can the OCC update TOBT directly?

Only where its authorised role and local agreement permit it. The German harmonisation FAQ reserves updates to the locally responsible person; Berlin requires a TOBT owner and an alert recipient. Software access should implement those responsibilities. ^{[12] [59]}

Are TSAT updates for airline operations the same as TOBT update events?

No. TOBT concerns readiness and TSAT concerns sequencing constraints. Berlin documents those different inputs, while Nice assigns the respective responsibilities to handlers and the airport operator. Maintain separate subscriptions or clearly typed records. ^{[3] [4] [5] [7]}

Does AIDX guarantee a usable A-CDM API?

No. IATA describes AIDX as a messaging standard. An actual integration also needs a verified endpoint or delivery channel, flight scope, credentials, revisions and agreed use rights. ^[30] SESAR likewise describes SWIM as broader than a single technology. (Source: www.sesarju.eu)

Conclusion

A-CDM TOBT TSAT integration is best specified as a controlled exchange of authoritative, time-bearing revisions. The operator should be able to explain what a value means, which actor owns it, whether a change was accepted, and how the current view was reconstructed. A timestamp without those relationships can be useful context, but it is insufficient evidence for automated reconciliation.

The source-of-truth matrix and airport access matrix provide complementary controls. The first keeps readiness, sequencing, flight-plan estimates, network allocations and actual movements distinct. The second identifies the local agreement needed to receive, retain or change them. Berlin's access documentation and Frankfurt's responsibility-transfer material demonstrate why those controls belong together. ^{[11] [16]}

Choose the existing airport or handler platform when its supported workflow already provides the required information and discrepancy handling. Choose an adapter when authorised sources must enter an existing operator system with clearer lineage, recovery and review. Public platform descriptions can inform that decision, but the final contract must be based on the deployed interfaces and permissions.

Before accepting an integration, test late revisions, duplicates, withdrawals, rejected submissions and forecast-versus-actual ambiguity. Separate canonical UTC comparisons from local presentation, retain the relevant mapping version, and give every unresolved discrepancy an owner. These controls make the operational picture explainable while leaving operational authority with the responsible partners and their applicable procedures.