EFB Data Revision Control: Tests Before Adding a Feed

Executive Summary

EFB data revision control is the operator's ability to identify which data revision belongs on each electronic flight bag (EFB), establish its validity and applicability, and retain evidence of the revision actually installed. A successful server upload is only an intermediate event. Federal Aviation Administration (FAA) guidance recommends making the loaded revision cycle evident; European acceptable means of compliance address matching cockpit content. ^[1] (Source: www.easa.europa.eu)

In the United States, FAA Advisory Circular (AC) 120-76E, issued June 12, 2024, is active and supersedes the previous D edition. It offers an acceptable means of authorization for operators including Parts 121 and 135, rather than a binding regulation. ( FAA AC 120-76E publication record In Europe, SPA.EFB.100 requires competent-authority approval for type B applications used by the operators within its stated scope, with risk assessment and an EFB administration system. ( EASA SPA.EFB.100 The retrieved European Union Aviation Safety Agency (EASA) consolidation is Revision 24, March 2026; its publication page instructs readers to check subsequently adopted rules. ( EASA Air Operations Revision 24 publication page

Before adding a chart, document, or dispatch-data feed, the administrator should request a version and delivery contract linking source identity, effective period, database cycle, aircraft applicability, integrity evidence, distribution status, installed version, last contact, acknowledgment, and rollback ownership. These are proposed procurement and acceptance criteria. They make the operator's existing administration process testable without turning a ground-side adapter into an approval authority. Jeppesen documents connection-dependent device reporting; Android's management API separately exposes the last status-report timestamp. Both illustrate why a reported version needs an observation time. ^{[2] [3]}

Offline availability and update completion require separate evidence. Ramco describes offline EFB activity followed by automatic synchronization, and myFLIGHTDATA documents offline support for applicable functions. Neither statement, by itself, answers whether a particular package was verified, installed, and acknowledged on every assigned device. ^{[4] [5]} A useful evaluation therefore demonstrates stale packages, wrong-tail assignments, corruption, partial synchronization, delayed devices, conflicting revisions, device mismatch, and controlled restoration of a previous release. The report confines those tests to ground-side integration and administration. Decisions affecting operations remain within the operator's applicable authorization, manuals, and change process.

Introduction and Background

The administrator's actual decision is whether a proposed feed can be supported within an existing EFB administration and change process. Operations control centre (OCC) leaders need an operationally intelligible status picture. Information technology (IT) teams need identifiers, interfaces, and failure semantics. Administrators need to relate those records to the application's installed content and the operator's configuration.

The data can include charts, company documents, or dispatch-related information. The distribution mechanisms differ: ForeFlight describes organization-controlled distribution of revised manuals, while Lufthansa Systems describes Lido mPilot as an iOS charting application containing operational information. Those published capabilities establish useful starting points, not interchangeable package schemas or administration contracts. ^{[6] [7]}

EFB data version control should distinguish three questions: what the source released, what the operator selected for distribution, and what each device reports as installed. FAA revision-control guidance concerns the current and complete database. ^[1] A proposed bridge should preserve revision identity throughout the process. Storing only the source's latest filename cannot demonstrate the device's installed state.

This report proposes a ground-side evaluation framework, with research current as of October 11, 2026. Its examples are hypothetical, and its test thresholds must be chosen by the operator. It does not prescribe which information crews should use in flight. An external feed cannot determine the scope of an operator's authorization or replace the administration manual.

A custom integration perspective is relevant where existing systems need a shared status model. LANDING.AERO describes connecting existing systems and data sources into unified platforms. Here that represents an adjacent integration option, rather than an EFB product comparison or a claim of certification capability. (Source: www.landing.aero) The appropriate purchasing decision may still be an established EFB platform with its supported administration tools.

Key Changes

United States: current FAA guidance and the operator's authorization

The essential source-currency change is to use AC 120-76E as the FAA reference, rather than treating D as current. FAA's publication record identifies E as active and shows the earlier edition in its cancellation information. ^{[8] [9]} The circular explicitly describes an acceptable means, but not the only means, of obtaining operational authorization for its intended operators. Its disclaimer states that the guidance does not have the force and effect of law. ^{[10] [11]}

The practical distinction is between a regulatory obligation, an accepted means of meeting it, and the procedures adopted by a particular operator. The circular's references to operator policy and authorization through A061 do not establish the contents of any specific airline's or Part 135 operator's approval. Those documents must enter the evaluation as operator-supplied evidence. ^[12]

For feed testing, the most directly relevant FAA recommendation is system verification with each database update. The circular also separates database revisions from application-software and operating-system (OS) changes. ^{[13] [14]} A replacement data package, a revised parser, and a changed mobile application should therefore have separate change records in the proposed evaluation.

FAA guidance distinguishes minor program modifications from significant modifications requiring formal review and evaluation. That distinction cannot be reduced to a supplier's description of a release as “just a feed.” The operator should document the classification using its authorization and administration process. ^{[15] [16]}

Europe: type B approval, administration, and change controls

For the European air operator certificate (AOC) context, SPA.EFB.100 requires type B approval for commercial air transport aeroplane/helicopter operators and innovative air mobility (IAM) operators. Its approval conditions include risk assessment and an EFB administration system addressing change and data management. (Source: www.easa.europa.eu) (Source: www.easa.europa.eu) (Source: www.easa.europa.eu)

The acceptable means of compliance (AMC) and guidance material (GM) accompany the rule. AMC2 addresses qualifying database changes without further approval and controlled testing. Eligibility must be documented for the proposed integration. (Source: www.easa.europa.eu) (Source: www.easa.europa.eu)

EASA's administration AMC addresses valid software versions and matching cockpit content. GM illustrates operational-report contents. (Source: www.easa.europa.eu) (Source: www.easa.europa.eu) (Source: www.easa.europa.eu)

Table 1 distinguishes the jurisdictions and the evidence a procurement team should request.

The table is a requirement-to-evidence map, not a common US and European approval checklist. The same technical test can support different operator processes, but it cannot establish that those processes or authorizations are identical.

Implementation Considerations and Process Changes

A feed assessment should begin with the existing controlled configuration. Record the application, supported device environment, data products, distribution service, administrative roles, and procedures affected by the change. FAA guidance recommends controlling and testing software, OS, and configuration settings; EASA AMC assigns configuration and valid-version responsibilities to the administrator. ^[17] (Source: www.easa.europa.eu)

Next, separate the data product from the delivery mechanism. A company manual may be revised independently of a chart database. A dispatch-data snapshot may have a short effective interval. Neither should inherit the chart feed's currentness merely because both arrived in the same synchronization session. ForeFlight's documented distinction between app updates and chart/data downloads offers a concrete example of separate lifecycles. ^[18]

The proposed change record should describe:

• Scope: Which source, content type, device group, and application consume the feed?
• Applicability: Which aircraft types, tails, or operational groups are eligible?
• Transformation: Is the content copied intact, indexed, converted, or recalculated?
• Dependencies: Which schema, application version, and configuration must accompany it?
• Approval boundary: Which existing operator procedure classifies and authorizes the change?
• Evidence: Which test results and device receipts demonstrate acceptance?
• Ownership: Who releases, rejects, investigates, and restores a package?

These are proposed implementation questions. A transformation that alters meaning deserves a different assessment from a bridge that displays the supplier's unchanged status record. The FAA distinction between database and application changes and the EASA conditional change AMC both make a single undifferentiated “update” category inadequate for evaluation.

EFB data update validation should also define what happens when evidence is missing. An absent device response, an unsupported schema, or an unexplained revision should enter an exception queue. The ground-side dashboard should preserve the uncertainty rather than substitute a successful server-side job result.

Assigning a release owner does not establish a universal retention period. FAA guidance differentiates catalog-change records from archives that must remain retrievable for the applicable retention period. Jeppesen documents a separate retention period for administrator activity, illustrating another distinct record class. ^{[19] [20]} Procurement should ask about device receipts, package archives, administrator actions, and acknowledgment records independently.

Finally, require repeatable evidence exports. Jeppesen's documented Activity Log comma-separated values (CSV) export illustrates concrete questions to ask other suppliers: which records can be extracted, with which identifiers, and whether timestamps remain available outside the user interface. ^[21] A screenshot can help a demonstration, but a reusable evidence package is more useful for later change review.

Version and Delivery Contract

Define identity before selecting transport

The proposed version and validity data contract is an agreement between the source, distributor, consuming application, and operator. It specifies the meaning of each identifier and state. It does not assume every supplier exposes the same fields.

A Hypertext Transfer Protocol (HTTP) entity tag (ETag) is a representation validator under Request for Comments (RFC) 9110. It can support transport-level conditional retrieval, but the operator should not equate it with a database cycle or approved revision unless the supplier defines that mapping. ^[22] Similarly, the National Institute of Standards and Technology (NIST) secure software development guidance describes release-integrity evidence and provenance. Those are useful engineering references, not EFB-specific mandates. ^{[23] [24]}

Table 2 specifies a proposed minimum contract. Fields may be supplied directly by the vendor or derived transparently by a bridge.

The contract should preserve source truth, delivery truth, and device truth as separate records. A source can publish a revision before it is effective. A distributor can finish transferring it before the application installs it. Apple documents distinct managed-app states, and Google's API exposes the last status-report time. Neither mechanism alone establishes application-level acceptance of a particular chart or document package. ^{[27] [3]}

Make conflicting revisions explicit

EFB conflicting data revisions need declared precedence rules. Ask how the system handles a repeated identifier with different bytes, overlapping effective periods, a late-arriving older package, or an assignment change during transfer. The proposed default for evaluation is to surface the conflict and preserve both evidence records until the responsible administrator resolves it.

Conditional HTTP retrieval helps avoid unnecessary transfers, but its validators describe web representations. They do not settle a disagreement between two authoritative-looking operational revisions. ^[22] Release records should therefore retain the source identifier and supersession relationship instead of assuming that the most recently received package is the correct one.

Integrity also needs careful wording. NIST describes digital signatures as authenticating the signatory and detecting unauthorized modifications. ^[25] A supplier's proposed checksum process should explain where its expected digest comes from and how that channel establishes the intended origin. ^[23] Comparing bytes and establishing authority are separate questions in the acceptance demonstration.

Acceptance Tests for Offline and Conflicting Revisions

Revision-state diagram (Hypothetical Example)

Assume a tablet disconnects while it holds Revision A. The source then publishes Revision B, and a connected tablet installs it. These are invented labels for a test, not a description of a vendor deployment.

The following proposed state model keeps the disconnected tablet at last observed A until new application evidence arrives. A distribution attempt must not overwrite that observation.

flowchart TD
    S[Source releases Revision B] --> D[Distribution queued or offered]
    D --> T[Transfer received]
    T --> V[Integrity and applicability verified]
    V --> I[Application reports B installed]
    I --> A[Required acknowledgment recorded]
    D --> O[Disconnected device: last observed A]
    O --> R[Reconnect and reconcile]
    R --> T
    V --> X[Rejected or quarantined]
    I --> B[Authorized restoration review]
    B --> R

The evidence chain should retain the event time and the observation time. Google's device API supplies a last-status-report timestamp, while NIST audit controls describe clock-based timestamps and preserving record ordering. These references support the proposed record design without specifying the operator's allowed delay. ^{[3] [28] [29]}

On reconnection, a ground-side bridge should expose which revision was offered, verified, installed, and acknowledged. If a response identifies A after B has been released, the display should retain that response and the target release separately. It should also show whether A's source-defined validity has ended. EASA's AMC supports easy verification of database validity and matching content across cockpit EFBs. (Source: www.easa.europa.eu) (Source: www.easa.europa.eu)

Acceptance matrix

Table 3 defines proposed ground-side acceptance tests. Each expected outcome is an evaluation criterion, to be reconciled with the operator's procedures and vendor architecture.

The matrix evaluates EFB offline data synchronization as a state-reconciliation problem. Availability of a cached file is useful, but it does not establish completion of a later update. ForeFlight describes offline retrieval from local storage; myFLIGHTDATA limits its offline statement to applicable functions and separately describes synchronization after connectivity returns. ^{[30] [5] [31]}

For each case, request evidence at the source, distribution service, and consuming application. A proposed acceptance pack should contain:

• Fixture: Source package, declared revision, applicability, and effective interval.
• Injection: The interruption, mismatch, corruption, or conflict introduced.
• Timeline: Source release, delivery attempts, device contact, and application receipt.
• Decision: Rejection, quarantine, pending state, or acceptance under the configured policy.
• Export: Machine-readable records that reproduce the displayed result.
• Owner: The person or role accountable for resolving the exception.

These checks make EFB data feed integration testing reproducible. They also expose where a vendor demonstration proves only one layer. An app-management report can establish an application version; an application-originated receipt is still needed to establish the proposed feed's installed content.

EFB data update rollback deserves a separate rehearsal. Apple's managed-app documentation states that pinning an older version does not automatically downgrade an already newer installed app. ^[32] Content restoration, app downgrading, configuration restoration, and withdrawing an invalid assignment are therefore separate test actions. No purchasing decision should assume that one rollback control performs all of them.

Vendor Capability and Approval Boundaries

Published vendor material can guide the demonstration, provided its scope and date remain visible. Jeppesen JDM Pro documents current, expired, missing, next-cycle, and unscheduled-update content states. Its device information is reported on connection, and its Devices list can be exported. Those capabilities give administrators concrete starting points for evaluating delayed devices and fleet status. ^{[33] [2] [34]}

ForeFlight documents distribution of revised organizational manuals and licensing of Jeppesen chart coverage for some or all group users. Its download guidance distinguishes local offline storage, application updates, and temporary Pack data. Procurement should therefore ask which content lifecycle and license scope apply to the proposed feed, rather than applying one synchronization assumption to every document and chart. ^{[6] [35] [36]}

Lufthansa Systems Lido describes mPilot for iOS and eRoute Manual for Windows. It also describes managing company information in mPilot. These are product-specific platform and content-management statements. They do not establish the supported OS release, hardware model, administration interface, or export rights for an operator's intended deployment. ^{[7] [37] [38]}

Ramco advertises offline EFB operation followed by automatic synchronization. myFLIGHTDATA documents applicable offline functions, synchronization of information entered offline, updated-document indicators, and searchable communication history. The required demonstration should distinguish document delivery, application data synchronization, and user acknowledgment, rather than assume the same event proves all of them. ^{[4] [31] [39] [40]}

For Airbus/NAVBLUE Mission+, Airbus's 2022 article describes iOS and Windows availability, automated data exchange with Flysmart+, and interfaces with other suppliers' applications. This is dated integration evidence, not confirmation of today's supported OS versions or the proposed adapter's compatibility. Obtain current deployment documentation before using it in a procurement specification. ^{[41] [42] [43]}

A structured vendor discussion should ask:

• Platform support: Which exact application, OS, device, and management-service combinations are supported?
• Content license: May the operator copy, transform, cache, redistribute, or export this data?
• Offline behavior: Which functions and content remain available, and what changes on reconnection?
• Installed version: Does reporting come from the device, application, distributor, or an inference?
• Log access: Can release, delivery, failure, and acknowledgment records be exported with stable identifiers?
• Conflict handling: How are duplicate identifiers, delayed revisions, and changed applicability resolved?
• Change boundary: Which configuration or application changes require operator review?
• Recovery: What can be restored, who authorizes it, and how is the resulting state verified?

myFLIGHTDATA's published offline and synchronization statements do not establish that every cached manual automatically receives its latest revision. ^[5]

Choosing an Established EFB or a Narrow Adapter

An established EFB vendor is the natural category to evaluate when the requirement includes the application itself, chart presentation, content subscriptions, device compatibility, or a supported administration environment. ForeFlight's organization-document distribution and Lido's charting applications are examples of published capabilities within that category. ^{[6] [37]} A custom ground-side integration should be scoped around the interfaces the selected environment actually supports.

A narrow data adapter fits a different problem: the operator already has its EFB applications and approved process, but needs to reconcile supplier releases, device reports, and internal assignments. Its proposed outputs are an evidence store, exception workflow, and exportable status view. It should not silently alter chart content, invent validity dates, or imply that its own status satisfies an authorization.

A build-versus-buy evaluation should distinguish:

• Distribution gap: The vendor already manages content, but its records need reconciliation with internal assignments.
• Evidence gap: Reports exist, but release and device identifiers cannot yet be joined reliably.
• Workflow gap: Exceptions need an owner, review queue, and documented resolution.
• Product gap: The operator needs an EFB application or licensed content service, which calls for that product category.
• Approval dependency: The proposed change affects the operator's existing application or administration process.
• Support dependency: Recovery depends on an interface or export that the supplier has not yet committed to support.

LANDING.AERO describes tailored flight-operations software, data integration, workflow automation, and dashboards. That makes custom integration a relevant adjacent perspective here. It does not establish a specific EFB connector, certification, supported tablet configuration, or vendor partnership. (Source: www.landing.aero) The builder's deliverable should be assessed against the same defined evidence contract as any other ground-side component.

The decision boundary becomes clearer when the operator asks what remains authoritative after the bridge is removed. Source revisions should remain traceable, vendor-installed records should remain interpretable, and the operator's procedures should still identify the responsible administrator. Jeppesen's documented CSV exports illustrate a concrete starting point for that portability discussion. ^[21] The contract should establish equivalent export and ownership terms for whichever solution is selected.

Data Analysis and Evidence

The most useful quantitative evidence is about effective dates, reporting latency, and retention scope, rather than broad EFB search volume or unsupported productivity claims.

EUROCONTROL's aeronautical information regulation and control (AIRAC) explanation states that information is distributed at least 42 days before effectiveness with the objective of reaching recipients at least 28 days beforehand. For major planned changes, it describes earlier publication, at least 56 days in advance, where desirable and practicable. These are publication-process intervals, not guaranteed tablet synchronization times. (Source: www.eurocontrol.int) (Source: www.eurocontrol.int) (Source: www.eurocontrol.int)

The FAA latest-editions table provides a concrete 2026 comparison: digital Terminal Procedures lists October 1 as current and October 29 as next, while digital Enroute Charts lists September 3 and October 29. Those product-specific entries demonstrate why “current cycle” needs a product identifier. They are not a universal update calendar for all EFB feeds. ^{[44] [45]}

Reporting cadence is another independent quantity. Apple says configured automatic managed-app update checks occur typically every 24 hours. That statement concerns app-management behavior, not an EFB data-feed installation deadline. ^[46] A supplier's demonstration should measure its actual package receipt and reporting sequence rather than substitute that platform interval.

Retention also has multiple scopes. FAA guidance recommends 3 months for EFB program catalog-change records; Jeppesen documents 365 days for administrator activities in its Activity Log. Those figures describe different records and should not be compared as competing compliance guarantees. Neither establishes the operator's required retention for every package, device receipt, or operational record. ^{[47] [20]}

Proposed measurement example (Hypothetical Example)

Assume an evaluated group has 24 assigned tablets. After a test release, 18 have application-confirmed installation, 3 are connected but pending, and 3 are offline with an older last observation. These are invented inputs. Confirmed installation coverage is 18 / 24 = 75%; each other group represents 12.5%. Reporting “all connected tablets updated” would obscure the assigned-device denominator.

The proposed dashboard metrics are:

• Installation coverage: Confirmed installations divided by applicable assigned devices.
• Observation age: Time since the latest application-originated status for each device.
• Delivery latency: Time from release availability to an observed distribution event.
• Acceptance latency: Time from release availability to application-confirmed installation.
• Exception count: Unresolved stale, applicability, integrity, conflict, and missing-receipt cases.
• Evidence completeness: Accepted releases with the required source, version, validity, and receipt fields.

Thresholds should be operator-defined. Jeppesen's connection-dependent reporting and Android's last-status-report field demonstrate why the observed population and age of its observations must accompany coverage calculations. ^{[2] [3]} The reviewed product pages establish feature claims, not a shared independently measured benchmark for end-to-end revision acceptance.

Implications and Future Directions

The immediate implication is that EFB data currency checks should become inspectable ground-side evidence. Administrators need to see the installed content identifier, its source-defined validity, and the freshness of the observation together. EASA AMC explicitly addresses easy verification of database validity, while FAA guidance emphasizes a readily evident loaded cycle. (Source: www.easa.europa.eu) ^[1]

The proposed architecture should keep technical acknowledgment separate from user acknowledgment. A device receipt establishes a reported machine state. A communication acknowledgment records a human interaction. myFLIGHTDATA's documented communication history is useful evidence for its stated communication feature, but it should not be generalized into a package-installation receipt without a demonstration. ^[40]

An EFB data revision audit trail should reconstruct the path from source release to assignment, delivery attempt, installed receipt, and exception resolution. NIST's audit guidance on timestamps and preserving original ordering provides design references. It does not prescribe a universal EFB logging schema or retention duration. ^{[28] [29]}

Future integration work should prioritize portable identifiers and reproducible exports. Jeppesen documents exportable device and administrator records; NIST's release guidance emphasizes retaining supporting provenance and integrity information. Together they suggest useful procurement questions about whether evidence remains understandable after a supplier, application, or bridge changes. ^{[34] [48]}

Automation can compare identifiers, calculate observation age, and route exceptions. Its decision authority should remain explicit. An adapter's determination that a release is “newer” does not establish source validity, aircraft applicability, or authorization for operational use.

The next useful improvement is a vendor demonstration in the operator's actual supported environment, using the acceptance fixtures and evidence contract. European administrators should keep the currentness check separate: EASA's publication page expressly directs readers to review later adopted rules, rather than assuming a consolidated edition is permanently complete. (Source: www.easa.europa.eu) That source discipline should also apply to compatibility matrices, content licenses, and supplier interfaces.

Conclusion

A new EFB feed should be evaluated as a versioned data product with observable delivery and installation states. The operator's decision depends on source authority, effective period, database cycle, applicability, integrity evidence, installed revision, observation age, acknowledgment meaning, and recovery ownership.

The strongest acceptance demonstration follows a revision through the source, distributor, and consuming application. It then introduces stale content, wrong-tail assignments, corruption, interrupted transfers, delayed devices, conflicting revisions, device mismatch, and restoration of a previous release. Each result should expose enough evidence for the administrator to reproduce the displayed status.

FAA guidance and European approval requirements belong in separate jurisdiction-labelled assessments. The operator's authorization, manuals, and change procedures determine the applicable administrative path. A ground-side bridge can help organize and reconcile evidence, while the established EFB application and licensed data environment remain essential parts of the evaluation.

The purchasing choice should follow the actual gap. Select an EFB vendor when the requirement is the product and its supported content ecosystem. Consider a narrow adapter when the requirement is reconciliation, exports, or exception workflow around existing systems. In either case, request the version and delivery contract before accepting the feed. The most consequential question is whether the operator can explain, from retained evidence, what each assigned device last reported and how that observation relates to the intended revision.