AIRAC Cycle Update Process for Flight Operations: Ledger

Executive Summary

AIRAC (Aeronautical Information Regulation and Control) is the International Civil Aviation Organization (ICAO) mechanism that puts pilots, dispatchers, controllers, flow managers, flight management systems and charts on one information base (Source: www.icao.int). It separates three dates: the publication date, when the State's aeronautical information service (AIS) sends the information out; the latest reception date; and the effective date (Source: www.icao.int). ICAO Annex 15 sets common effective dates at intervals of 28 days (Source: www.icao.int), which yields 13 cycles in a normal year (Source: www.eurocontrol.int). As of 18 October 2026, cycle 2610 took effect on 1 October and cycle 2611 takes effect on 29 October (Source: www.eurocontrol.int).

The lead-time rules are specific. AIS distributes AIRAC information at least 42 days before the effective date, aiming to reach recipients 28 days ahead (Source: www.icao.int), and Annex 15 recommends at least 56 days for major changes (Source: www.icao.int). Information published under AIRAC is not changed again for at least 28 days after the effective date (Source: www.icao.int), and a NIL notification is issued when a State has nothing to publish (Source: www.icao.int). These milestones define what an operator can later prove: the interval between reception and effectivity is the window in which provider packaging, ingestion, staging and verification must happen.

The gap this report addresses is evidentiary. EUROCONTROL's national AIRAC publication review table gives a quick overview of what ECAC and neighbouring States have made available for the next three cycles (Source: www.eurocontrol.int), and calendars give dates. Neither shows whether a given amendment reached an operator's flight-planning data, route-validation reference and chart reference. Public provider material is partial: Jeppesen publishes a per-cycle release statement ^[1], and Collins sends a Database Availability email each release cycle as formal notification ^[2]. This research found no public documentation of a per-consumer activation record for any provider. The result is a reference ledger (Table 1) with fields from State source to exception owner, and a UTC timeline for cycle 2611 (Table 2).

Operator duties differ by jurisdiction. The United States requires an approved system for obtaining, maintaining and distributing current aeronautical data for Part 121 airports ^[3]. The European Union requires timely distribution and insertion of current and unaltered aeronautical databases (Source: eur-lex.europa.eu). Canada's Standard 725 requires aeronautical information to be current per the AIRAC schedule, in a provision shown as effective 10 April 2026 ^[4]. A packaged provider is sufficient where it exposes cycle identifiers, release timestamps and a change summary that the operator can match to each consumer; a narrow, operator-specific reconciliation bridge is worth considering only where that evidence stops. This report is analysis, not operational guidance, and does not replace an operator's approved procedures, operations specifications or manuals.

Introduction and Background

This report examines how a change published in a State's AIP amendment becomes effective, and can be shown to be effective, inside the ground systems of an airline, charter operator or flight department. The audience is operations control centre (OCC) managers, dispatch data owners and integration engineers who must decide whether their aeronautical-data provider and their own systems can demonstrate that a published AIRAC change reached every dependent planning workflow. The scope is ground-side data governance. It is not avionics certification, it does not instruct flight crews, and it treats the flight management system (FMS) only as a dependent system that an approved specialist maintains.

ICAO states the rationale plainly: AIRAC exists so that everyone works "from the same information base" (Source: www.icao.int). Annex 15 requires circumstances such as changes to airspace limits, procedures, navaids, runways and lighting to be notified through AIRAC on common effective dates (Source: www.icao.int), and bars non-AIRAC implementation dates for pre-planned, operationally significant changes that need cartographic work or navigation database updates (Source: www.icao.int). ICAO regional guidance adds that common dates let every actor in the data chain, including data integrators and aircraft operators, meet its obligations on time (Source: www.icao.int).

Jurisdiction matters. ICAO publishes Standards and Recommended Practices; States implement them and may file differences. Ireland's AIS guidance, for example, states that any differences are published in AIP Ireland GEN 1.7 (Source: www.iaa.ie). The paragraph numbers cited below come from the consolidated Annex 15 text (16th Edition including Amendment 41) hosted by ICAO; readers should confirm them against the edition applicable in their State, because the in-force PANS-AIM (Doc 10066) text could not be retrieved for this research.

Calendars usually list only the effective date. The operator's question is different: for a named change, when did the State publish it, when did the provider release it, and when did each internal consumer activate it? The ledger proposed here answers that per change and per consumer.

LANDING.AERO is a Montreal software studio that builds custom flight operations software, including integrations that bring existing data sources into one operational picture. It does not sell an off-the-shelf operations platform, is not an avionics or certified airborne-software developer, and is not a dispatch or flight-following service. Its perspective is one of several in this report: the central argument is about evidence, and many operators will meet it with a provider's own tooling.

Key Changes: How an AIRAC Amendment Moves from State to System

Stage 1: State publication, reception and effectivity

The State's AIS is the origin. Annex 15 requires AIRAC information to reach recipients at least 28 days before the effective date, and a note says the AIS distributes it at least 42 days ahead to meet that objective (Source: www.icao.int). EUROCONTROL's AIRAC dates page restates the 42-day rule (Source: www.eurocontrol.int). Irish AIS guidance restates the same NIL and lead-time rules for its users (Source: www.iaa.ie).

Two further rules shape the ledger. Once effective, AIRAC information is not changed for at least another 28 days, except for temporary circumstances (Source: www.icao.int). And where nothing was submitted by the AIRAC date, a NIL notification is distributed no later than one cycle before the effective date (Source: www.icao.int). A NIL is therefore a positive statement, not an absence, and the ledger should record it as a received item.

Visibility of State publication status is available in Europe. EUROCONTROL's national AIRAC publication review (NAPR) is a table for the next three cycles, updated as new information comes in (Source: www.eurocontrol.int). On 18 October 2026 it showed columns for cycles 2610, 2611 and 2612 (Source: www.eurocontrol.int), listed 40 ECAC States plus a second table of neighbouring States (Source: www.eurocontrol.int), and carried a legend marking amendments that cover the ATS route network and free route airspace (Source: www.eurocontrol.int). The page showed no as-of date stamp when read. It reports whether a State has made information available, which is a State-side fact; it is not evidence about any operator's systems. A EUROCONTROL-related performance reference cites the dates page for "details about the AIRAC cycles and the corresponding dates" (Source: ansperformance.eu), which shows its role as a schedule.

Cancellation and postponement are constrained. ICAO regional guidance quotes Doc 8126 to the effect that a NOTAM cancelling AIRAC information less than 28 days before the effective date does not generally allow sufficient time for previously valid information to be reinstated in airborne databases (Source: www.icao.int). Operators should therefore treat late State changes as an exception class of their own.

Stage 2: Data houses, formats and provider packages

Between the State and the operator's systems sit data providers. Their output is typically a navigation database coded to ARINC 424, a standard published by SAE Industry Technologies Consortia for the preparation of a navigation system database ^[5], plus charts and, increasingly, structured data. Jeppesen states that NavData is available as raw ARINC 424 ^[6]. Skywise states that Navigation+ updates 10,000 records in each 28-day cycle ^[7]. Lufthansa Systems states that it produces around 400 database extracts per cycle tailored to each customer's aircraft types, route network and procedures ^[8]. These are vendor statements, not independent measurements.

RTCA DO-200B sets minimum requirements for processing aeronautical data ^[9], and when applied by each organisation in the data chain it gives assurance that data quality is established and maintained ^[9]. The FAA's Advisory Circular (AC) 20-153B lists the quality characteristics as accuracy, resolution, assurance level, timeliness, completeness, traceability and format ^[10], and describes the FAA Letter of Acceptance (LOA) for a supplier's data process ^[10]. EUROCAE publishes ED-76B as the updated European counterpart ^[11]. In the European Union, EASA states that operators using aeronautical databases on certified systems must ensure the provider is a Type 2 data service provider certified by EASA, or equivalent (Source: www.easa.europa.eu).

Integrity evidence is a distinct matter. An ICAO Air Navigation Conference working paper restates the Annex 15 requirement that digital data error detection techniques be used during transmission (Source: www.icao.int), and AC 20-153B requires suppliers to define how they confirm that received data is not corrupted ^[10]. EASA's Part-DAT guidance notes that a provider may use digital data sets to support data integrity (Source: www.easa.europa.eu). None of the public sources read for this research names a checksum field in a provider's per-cycle package, so any checksum row in the ledger is "if supplied", exactly as the contract with the provider defines it.

The data model beneath state publication is also changing. The Aeronautical Information Exchange Model (AIXM) aims to enable the provision of aeronautical information in digital format (Source: aixm.aero), and ICAO AIP and obstacle data sets are specified on AIXM 5.1.1 (Source: aixm.aero). AIXM carries temporality through baseline and temporary time slices (Source: aixm.aero), which is why a ledger needs both a change identifier and a validity interval.

Providers also publish per-cycle artefacts that a ledger can reference. Jeppesen's NavData page lists a 2026 cycle schedule ^[12]; a per-cycle release statement lists the cycle number and release date, for example a release date of 13 October 2026 for cycle 2611 ^[1]; and a NavData Modified Data Report exists because regulators require Jeppesen to tell end users about data it modified from State-provided data ^[13]. Jeppesen's Notices page says its NavData Alerts are designed to inform commercial subscribers ^[14]. Collins publishes a Database Effectivity Schedule page on its portal ^[15]. Dependent avionics providers need time too: Irish guidance notes that FMS data often has to be with the data house about 20 days before the effective date (Source: www.iaa.ie). Use the applicable supplier commitments and the operator’s defined or accepted timeliness requirements to assess package delivery; this approximate processing allowance does not establish one universal finished-package deadline ^[10].

Stage 3: Ground-side consumers

Four ground consumers recur in dispatch environments; they are named generically here because architectures differ.

• Flight-planning data: the performance, airway, waypoint and airport database inside the operator's planning engine, typically loaded from the provider package.
• Route-validation reference: the external authority against which filed routes are checked, such as the Network Manager's Integrated Initial Flight Plan Processing System (IFPS) in Europe or FAA preferred-route data in the United States.
• Chart reference: terminal procedure and enroute charts used by dispatchers and flight crews, delivered on a product-specific cadence.
• Exception and notification channel: NOTAM, trigger NOTAM and provider alerts used when the cycle is not the whole story.

The route-validation reference is the most testable, because in Europe it is externally enforced. The IFPS manual (WAVE-2.3, validity 22 April 2026) states that IFPS invalidates a message with a date of flight for which no AIRAC data is available (Source: www.eurocontrol.int), and that this avoids processing a message for the next AIRAC before the data is loaded (Source: www.eurocontrol.int). The IFPS manual, §26 limits checking against the later AIRAC to a specific set of errors; operators should treat this as limited external evidence and design their own acceptance coverage accordingly. The Route Availability Document (RAD), described as designed as a sole-source flight-planning document (Source: www.eurocontrol.int), has its cut-off at the AIRAC publication date, 42 days before the effective date (Source: www.eurocontrol.int), and publication 28 days before the cycle (Source: www.nm.eurocontrol.int); RAD restrictions are implemented on the AIRAC calendar as far as possible (Source: www.eurocontrol.int). The Network Manager's own static data reaches a final cut-off at AIRAC minus 10 days (Source: www.eurocontrol.int), and early access to the next cycle in the IFPS validation facility is described as provisional (Source: www.eurocontrol.int). The European AIS Database lets a user retrieve a dedicated data set at defined intervals such as an AIRAC cycle (Source: www.eurocontrol.int).

In the United States the equivalent evidence is the FAA's National Airspace System Resource (NASR) subscription. The FAA says it disseminates aeronautical information in accordance with the AIRAC cycle ^[16]. The NASR page lists Subscription effective October 29, 2026 as the preview ^[17], and the README says the FAA is now issuing these products on a 28-day cycle periodicity ^[18]. File sets are posted 28 days before their effective date ^[18]. The 29 October 2026 set is a 56-day major cycle ^[18] that incorporates daily National Flight Data Digest data through NFDD 186 dated 28 September 2026 ^[18]. Because FAA policy updates some resources only on the 56-day basis ^[18], a consumer showing "no change" on a 28-day cycle can be correct. The FAA’s 29 October 2026 NASR README also documents the TXT-to-CSV migration: following the 3 September 2026 release, legacy TXT files no longer contain new NASR data entrants; new entrants are available only in CSV. It announces that TXT downloads cease beginning 21 January 2027 ahead of the 18 February 2027 effective cycle, and identifies a Legacy TXT to CSV Mapping Document on the main 28-Day Subscription page. Record the actual subscribed format and migration owner, retain the FAA mapping document as acceptance evidence, and test new-record completeness alongside cycle identifiers. The FAA also changes file structure on AIRAC dates: its preferred routes file changed effective the 3 September 2026 AIRAC cycle ^[19], and AIXM 5.1 versions of navaid, airport and airway files are offered ^[20]. FAA Order JO 7210.3EE states that the order and its changes are scheduled to be published to coincide with AIRAC dates ^[21].

Charts follow product-specific cadences. The FAA digital Terminal Procedures Publication is published every 28 days ^[22] and reprocesses all of its roughly 17,000 files in each cycle ^[22], whereas the Chart Supplement is issued every 56 days ^[23]. NAV CANADA states its publications are updated in alignment with the AIRAC cycle ^[24], with AIP Canada, the Canada Air Pilot, the Canada Flight Supplement and the enroute and terminal charts revised on a 56-day cycle ^[24], while AIP Supplements and Aeronautical Information Circulars use a 14-day cycle ^[24]. A ledger that assumes one cadence for all consumers will therefore report false mismatches.

Stage 4: Operator obligations by jurisdiction

The regulatory hooks differ in wording, and none of them is a ledger requirement. They are context for what evidence an operator may want when asked to show that data was current.

• ICAO Annex 6 Part I: the operator must not employ electronic navigation data products unless the State of the Operator has approved procedures for ensuring integrity and compatibility (Source: www.bazl.admin.ch), and must implement procedures for timely distribution and insertion of current and unaltered data (Source: www.bazl.admin.ch).
• United States (14 CFR): Part 121 domestic and flag operators need an approved system for obtaining, maintaining and distributing current aeronautical data ^[3], must keep the operations manual current ^[25], and dispatchers must give the pilot in command current reports on airport conditions and navigation-facility irregularities ^[26]. Part 91 subpart F operators of large and turbine-powered aeroplanes must have charts and data in current and appropriate form accessible for each flight ^[27]. Part 121 does not use the word AIRAC in these provisions; the closest explicit term is "current".
• European Union (Regulation 965/2012): CAT.IDE.A.355 requires timely distribution and insertion of current and unaltered databases (Source: eur-lex.europa.eu), and requires the operator to report erroneous, inconsistent or missing data to the provider (Source: eur-lex.europa.eu). The commander must be satisfied that any navigational database required for performance-based navigation is suitable and current (Source: eur-lex.europa.eu). Contracted services must comply with applicable requirements and be covered by the management system (Source: eur-lex.europa.eu). EASA guidance says distribution should follow the database validity period or an operations manual procedure (Source: www.easa.europa.eu).
• Canada: CAR 602.60 requires necessary current aeronautical charts and publications covering the route ^[28], and a current database where database-dependent equipment is used under the listed Parts VI and VII subparts ^[28]. Standard 725 requires aeronautical information to be current per the AIRAC schedule effective dates, where applicable ^[4], and for GPS approaches requires procedures to ensure the database is updated per the data revision cycle ^[4]. Standard 725 also requires flight dispatch centres to be supplied the information needed to formulate an operational flight plan ^[4].

Charter operators and flight departments sit under different subparts, such as Part 135 or Canadian 704/705 and Part 91, but the same ledger logic applies; only the approvals and manuals that define "current" differ. Consult the operator's own regulator, operations specifications and approved manuals.

Implementation Considerations and Process Changes

The reference ledger

Table 1 below lists the fields of a cutover ledger. One row exists per change per consumer, so a single State amendment that touches a runway and two procedures creates several rows. The template is a proposal for governance, not a regulatory form.

The table is only useful if the provider and the operator's systems can fill it. Regulators already point in this direction: AC 20-153B states that tailored data originated by an operator for its own use remains the operator's accountability ^[10], and EASA's Part-DAT guidance excludes from certification databases provided or used by the operator and monitored under its responsibility (Source: www.easa.europa.eu). Data that is the operator's own is also the operator's to reconcile. The timeliness requirement itself is expressed as the data being valid for its period of use ^[10], which is precisely what an effective-time ledger documents. Retention helps: EASA's Part-DAT guidance has providers keeping records for at least 3 years (Source: www.easa.europa.eu), a useful reference for how long an operator might retain its own ledger.

Cutover timeline for cycle 2611

Table 2 below anchors the ledger to a real cycle. Cycle 2611 takes effect on 29 October 2026 (Source: www.eurocontrol.int). Dates marked "computed" are calendar arithmetic from the cited rule, not published per-cycle dates; EUROCONTROL's schedule gives the rule and effective dates, not per-cycle publication dates.

The timeline shows that a "reception" milestone is not one event. The FAA data cut-off is 31 days out, the ICAO reception objective is 28 days out, a vendor package may arrive 16 days out, and Network Manager's provisional data appears 14 days out. The ledger's purpose is to hold each of these against the effective date, per consumer. A related discrepancy: NAV CANADA's AIP Canada page says the next issue is posted no later than ten days before the effective date ^[30], which differs from the 28-day reception objective (Source: www.icao.int). The two statements describe different artefacts (a public posting versus distribution to recipients), and a ledger should record which artefact each timestamp belongs to.

Record the authoritative effective timestamp and validity interval for every affected State change and product from its applicable publication. An internal cutover plan cannot redefine that effectivity. For example, FAA Order JO 7400.2, §2-3-7 prescribes 0901 UTC for amendments to Parts 71 and 73, subject to the exceptions listed there; this is not a universal time for all AIRAC products. Record planned internal cutover, advance staging and actual operational activation separately, and select data valid for the relevant flight period across cycle boundaries ^[10].

Lag calculation. For each change/product, calculate operational activation lag as actual operational activation time minus its applicable authoritative effective timestamp. Measure deviation from the planned internal cutover as a separate metric. Staging has its own timestamp and is not operational activation. A negative value triggers a validity check: it is premature use if the data is applied to a flight period before validity begins. A positive value triggers review of affected flights for delayed availability. Neither value authorizes operational use outside the applicable validity interval ^[10].

(Hypothetical Example) Suppose the authoritative source for an illustrative change/product specifies validity starting at 29 October 2026 09:01 UTC. This is an invented source condition, not a claim that cycle 2611 has one universal effective time. Non-live staging at 08:56 has a staging lead of 5 minutes and no operational activation lag. Operational activation at 09:01 has zero lag; activation at 09:11 has +10 minutes of lag and requires review of affected flights. Applying that data to an operation occurring at 08:56 would be premature. Planning in advance for a flight period within the new data’s validity requires flight-time-dependent selection, not a blanket wall-clock switch. Keep each flight associated with the data valid for its relevant period; do not retain expired data as a fallback ^[10]. All timestamps and outcomes in this example are synthetic and are not performance benchmarks or release approvals.

Acceptance tests

Acceptance tests turn the ledger into a decision aid. Each is written as a scenario, a check and an expected record. They are test designs, not operational procedures.

1. Missing State amendment

• Scenario: the NAPR table shows an amendment reference for a State, but the provider's change summary has no corresponding record, or the State shows NIL while a consumer shows a delta.
• Check: reconcile State source rows against provider and consumer rows. A blank NAPR cell is not a NIL and should be treated as unconfirmed.
• Expected record: a row with status "unmatched", an exception owner and a link to the NIL rule (Source: www.iaa.ie).

2. State/AIS reception and provider-package timeliness

• Scenario: State/AIS information misses its applicable reception milestone, or a processed provider package misses a documented delivery commitment or the operator’s validated ingestion window.
• Check: assess State/AIS recipient reception against the Annex 15 reception requirement. Assess the processed package separately against its documented provider release schedule, contractual delivery commitment and validated ingestion window; document which requirement applies and compare the appropriate release or receipt timestamp. The operator defines completeness and timeliness requirements or accepts its supplier’s requirements ^[10]. A later provider-package release is not automatically a failure of the State/AIS reception milestone.
• Expected record: the relevant artefact, applicable requirement and deadline, release/receipt timestamp, measured deviation, affected flights, exception owner and approved response. Confirm data validity before any fallback operational use.

3. Mismatched cycle IDs

• Scenario: one consumer shows 2610 while others show 2611.
• Check: confirm whether the mismatch is real or a product cadence difference. FAA NASR change-notice cycles repeat some files from the previous major cycle ^[18], and Chart Supplement editions follow 56 days ^[23].
• Expected record: a per-product cadence table and a validation result that distinguishes "behind" from "not due".

4. Rollback and postponement

• Scenario: a State postpones or cancels a change, or an internal deployment fails and recovery is required.
• Check: retain the previous package for recovery and evidence, but verify its authoritative validity for every affected flight before any operational reuse. Recovery must not reactivate expired data. If no valid package covers the intended operation, record an exception under the operator’s approved procedure rather than accepting a technically successful rollback. FAA AC 20-153B, §13.1.2 addresses validity for the period of use. ICAO guidance warns that previously valid information may not be reinstated in time when cancellation is late (Source: www.icao.int), and NAV CANADA reminds originators that an FMS may not contain critical data established by NOTAM ^[31].
• Expected record: authorisation, affected consumers and flights, authoritative validity evidence, recovery/staging times, actual operational activation times, and any unresolved exception.

Two supporting tests: use the IFPS validation system (IFPUV) for non-operational pre-validation, retaining results locally because those test plans are not stored. In the operator’s own test environment, verify flight-time-dependent data selection before, across and after each applicable validity boundary, including in-flight cycle transitions and delayed departures; external validation is only one part of that acceptance evidence. Separately, test parser compatibility and new-record completeness in the actual subscribed NASR format, recording the migration owner, FAA Legacy TXT to CSV Mapping Document and test results ^[18]. A parser pass and a current cycle ID alone are insufficient acceptance evidence.

Cutover checklist

The following checklist condenses the above for a single AIRAC cutover. It is a governance aid for data owners, to be adapted to the operator's approved procedures.

• Before the reception date: confirm the cycle ID, the AIRAC calendar entry and the list of States with amendments of interest; record NIL notices as received items.
• At provider release: log package ID, release time and any change summary or modified-data report; record the checksum if the provider supplies one.
• Staging: load into non-live instances; run schema and cross-cycle flight tests; record staged times in UTC.
• Before each applicable authoritative effective timestamp: verify the source timestamp, validity interval, approvers and exception owner; retain recovery packages and confirm validity before any operational reuse.
• At operational activation: record the actual timestamp per consumer and change/product, calculate lag against authoritative effectivity, and flag premature or delayed use. Maintain flight-time-dependent data selection across cycles and prevent operational use outside validity ^[10].
• After cutover: run route-validation spot checks against the external reference; reconcile open exceptions; archive evidence.
• Next cycle: review whether any amendment is protected from further change for 28 days (Source: www.icao.int), and carry forward unresolved exceptions.

Packaged provider versus a narrow reconciliation bridge

Whether a bridge is needed depends on what the provider exposes. Table 3 compares three ways to produce ledger evidence. It is not a vendor ranking; the first row describes a capability class, and the third row describes the posture of the publisher of this report.

A bridge adds a component that itself needs ownership, change control and testing. It sits in the operator's data governance, not in the airborne chain, and does not change what the provider, the State or the regulator requires. It should never be the sole evidence in an approval: the provider's and State's own documents remain the primary record. Where a team wants alarms at the effective instant, small single-purpose tools exist, such as a Zulu-time alarm utility; and a NOTAM change alert tool is announced as coming soon by the same publisher and is not generally available, so it should not be assumed in any plan.

Boundaries with EFB administration and certified airborne data

Two adjacent topics are deliberately outside this report. Electronic flight bag (EFB) data revisions concern delivery and version status on devices; FAA AC 120-76E recommends a means to identify the database version, effective date and valid operating period ^[32] and that it be readily evident which revision cycle is loaded ^[32]. That belongs to EFB administration. Certified airborne data concerns the FMS and similar equipment. The FMS database is produced and loaded under the controls of the data process standards and the approved specialist who maintains it, and for European operators EASA expects a Type 2 provider or equivalent (Source: www.easa.europa.eu). A ground ledger can record that a package was released for those systems, but it does not load, certify or approve them. Operational release remains with the operator's approved procedures.

Data Analysis and Evidence

The quantitative core is calendar arithmetic and published lead times. The points below consolidate the figures from Table 2 and their originators.

• Cycle count and interval: 28-day intervals; 13 cycles in a normal year, so one month has two. In 2026 that month is October (2610 on 1 October and 2611 on 29 October). EUROCONTROL's published schedule lists 2612 on 26 November and 2613 on 24 December 2026, and 2701 on 21 January 2027 (Source: www.eurocontrol.int).
• Lead times: 42 days for AIS distribution and 28 days for recipient reception; 56 days recommended for major changes. For cycle 2611 these computed dates are 17 September, 1 October and 3 September 2026 respectively, as shown in Table 2.
• Cut-offs observed in operator-relevant systems: FAA NASR data cut-off 31 days before the 29 October 2026 effective date ^[18]; Network Manager RAD cut-off 42 days (Source: www.eurocontrol.int); ENV static data cut-off at AIRAC minus 10 days; a vendor release 16 days before effectivity for cycle 2611 ^[1].
• Freeze rule: NAV CANADA states information must not be further changed from 28 days before the effective date until 28 days after, unless temporary ^[31], which corresponds to the Annex 15 rule. NAV CANADA also states that all updates to critical information must become effective on an AIRAC date ^[31].
• Cadence mix: 28-day FAA digital procedures ^[22], 56-day Chart Supplement ^[23], 56-day NAV CANADA publications ^[24], 14-day NAV CANADA supplements ^[24]. With five consumers and 13 cycles a year, a per-consumer attestation costs 65 ledger entries per year per change class (a simple product, assuming one row per consumer per cycle).
• Trigger NOTAMs: NAV CANADA issues one Trigger NOTAM per NOTAM region 14 days before the effective date for AIRAC AIP amendments ^[29].
• Planning constraints: NAV CANADA has told users that its transition to a new aeronautical data processing system constrains submission capacity, most significantly in the 15 April 2027 and 10 June 2027 cycles ^[33], while the format, content and scheduled release of cyclic 56-day publications remain unchanged ^[33].

These numbers carry three caveats. First, source discrepancies are real: the ICAO reception objective (28 days) and NAV CANADA's public AIP posting (ten days before) refer to different artefacts. Second, the publication and latest-reception dates per cycle are not listed in the EUROCONTROL schedule; they are computed here. Third, the lag figures in the earlier example are synthetic and must never be quoted as performance data. No public benchmark of operator activation lag was found.

Evidence quality varies by claim. State and calendar facts come from ICAO, EUROCONTROL, the FAA and NAV CANADA directly; provider facts come from the providers' own pages and are vendor claims; regulatory facts come from the primary legal text.

Implications and Future Directions

For operators, the practical implication is that evidence design should precede tool choice. A team that cannot name its consumers, their cadences and the owner of each exception will not benefit from an additional integration. A team that can name them, but finds activation times only in logs of separate systems, has a reconciliation problem that is narrow and well bounded.

For providers, the public material read for this research shows release statements, alerts and availability emails, but no public per-consumer activation record. Customer-only portals may expose more; the data-owner question for contract review is which cycle identifier, release timestamp, change summary and checksum field the provider supplies, in which format, and for how long it retains them. Provider claims about FAA LOA acceptance of an aeronautical-data process ^[10] and EASA certification of organisations processing aeronautical data for use on aircraft (DAT providers) ^[34] should be identified separately and matched to the evidence the operator's own regulator accepts.

For standards, the data-quality ecosystem is moving. EUROCAE lists ED-76B with Corrigendum 1 as the latest version of its standard ^[11]; EASA's Part-DAT guidance names ED-76A and DO-200B for validating aeronautical data (Source: www.easa.europa.eu). Operators should check which edition their provider's approval references. AIXM adoption is extending digital exchange (Source: aixm.aero), which could make machine-readable change identifiers more available over time, though no operator-facing guarantee follows from that.

For States, ICAO's MID regional guidance recommends AIRAC adherence monitoring (Source: www.icao.int). Operators cannot control State timeliness, which is why the exception owner field matters.

Frequently Asked Questions (FAQs)

What is the AIRAC cycle update process for flight operations?

It is a 28-day cycle in which States publish operationally significant aeronautical information in advance on common dates (Source: www.icao.int). Operators receive it through providers and State AIPs, load it into planning, route-validation and chart systems, and the changes become effective on the AIRAC date (Source: www.icao.int).

What are the AIRAC effective dates and cut-offs?

Effective dates in late 2026 are 29 October (2611), 26 November (2612) and 24 December (2613), then 21 January 2027 (2701) (Source: www.eurocontrol.int). Cut-offs depend on the artefact: 42 days for AIS distribution (Source: www.icao.int), 28 days for reception, 56 days recommended for major changes (Source: www.icao.int), and system-specific cut-offs such as the FAA and Network Manager dates in Table 2.

How do I implement an AIRAC cycle in a flight planning system?

Treat the provider package as a controlled input: record its cycle ID, release time, authoritative effective timestamp and validity interval. Record planned internal cutover, non-live staging and actual operational activation separately. Operational selection must use data valid for the relevant flight period across cycles; an internal deployment target cannot redefine effectivity ^[10]. The data-quality standards for the provider side are DO-200B and ED-76 family documents ^[9]. Consult the operator's regulator and approved procedures for what must be approved.

What does an ARINC 424 workflow look like?

ARINC 424 is the record standard for navigation system databases ^[5]; providers such as Jeppesen offer it as raw data or in proprietary formats ^[6]. The workflow is: provider builds from State data, operator or avionics specialist ingests, tests, and loads. The ground ledger records the package, not the avionics load.

Which data validation applies?

Validation has several layers: the provider's quality process, the operator's acceptance tests, and external validation such as IFPS checks (Source: www.eurocontrol.int). Operators in the EU must also report erroneous, inconsistent or missing data to the database provider (Source: eur-lex.europa.eu).

Does this apply to charter operators and flight departments?

Yes in principle. The AIRAC calendar is the same, while the obligations differ: for example Part 91 subpart F ^[27] or Canadian CAR 602.60 ^[28]. A smaller operator may satisfy the ledger with a spreadsheet and a provider portal rather than a bridge.

Conclusion

An AIRAC cycle is a coordination device with three dates, a 28-day rhythm and a set of published lead times. Calendars and State publication tables describe what should happen; they do not show what happened inside an operator's planning, route-validation and chart systems. The ledger proposed in this report fills that gap by recording, for each change and each consumer, the State source, the three dates, the provider package, the consumer version, the activation time, the validation result and the exception owner.

The decision for OCC managers and dispatch data owners is evidence-based. If the provider's release documents, the consumers' audit logs and the external validation references can be joined with modest effort, a packaged provider plus disciplined records is sufficient. If activation evidence is scattered across systems that do not export it, a narrow, operator-specific reconciliation bridge is a reasonable option to evaluate, alongside in-house scripts. In either case, the ledger supports an operator's own approvals; it does not replace operations specifications, manuals or the judgement of the people accountable for operational control.