Electronic NOTOC Revisions: Handoff and Receipt Tests

Executive Summary

Electronic NOTOC revisions require a demonstrable connection between the changed information, its current edition, the intended recipients and the pilot's receipt. In the United States, 49 CFR 175.33 permits electronic information, requires delivery no later than aircraft movement under its own power, and requires a written indication of receipt from the pilot in command (PIC). ^[1] The Pipeline and Hazardous Materials Safety Administration (PHMSA) confirms electronic delivery and ready ground access to both the shipping paper and PIC information. ^[2]

The practical procurement question is whether a loading-position change can be followed from its source to the flight deck and ground records without confusing delivery with human receipt. WinOps describes NOTOC delivery with captain acceptance or rejection. (Source: www.winops.aero) DynamicSource describes joint loadsheet and NOTOC signing and edition-specific acceptance in its load-control workflow. (Source: www.dynamicsource.se) These are documented vendor capabilities, not independent evidence that every NOTOC-only revision is reconciled across an operator's configured systems. A useful evaluation therefore asks for a replayable change scenario, including an offline device, delayed receipt and ground retrieval.

The US recordkeeping anchor is 90 days for PIC information, with separate shipping-paper requirements. ^[1] The European comparison has a different time boundary: the European Union Aviation Safety Agency (EASA) publishes an acceptable means of compliance (AMC) addressing changed dangerous-goods loading positions, an amended NOTOC, commander receipt and an accessible ground copy. (Source: www.easa.europa.eu) It is explicitly applicable from March 27, 2028. (Source: www.easa.europa.eu) It must not be presented as already applicable in October 2026. International Civil Aviation Organization (ICAO) public material identifies the current Technical Instructions edition but does not replace access to its complete licensed text. (Source: www.icao.int)

This report proposes an information and acknowledgment contract, a field-and-owner test matrix, and a synthetic revision timeline. These are engineering acceptance criteria, not additional regulatory rules or an automated departure decision. The preferred outcome is evidence that the current edition is readable, receipt is attributable, superseded records remain traceable and an exception has an accountable owner. An operator should resolve the procedure and authorization questions alongside the software work; FAA material describes submitting dangerous-goods manual revisions through the principal operations inspector. ^[3]

Introduction and Background

A notification to captain, or NOTOC, is an information handoff. Its useful boundary is the dangerous-goods information provided to the flight deck and the ground functions that need it. It is distinct from the weight-and-balance calculation and final load manifest. The US rule allows the shipping paper and PIC information to be combined, but separately addresses their availability and retention. A shared document does not eliminate the need to identify which requirement each record satisfies. ^[1]

The report addresses US Part 121 and Part 135 dangerous-goods, load-control, dispatch and information technology (IT) teams evaluating an electronic workflow. FAA's current electronic flight bag (EFB) advisory circular addresses operational authorization for these operator categories, among others, when replacing required paper information. ^[4] The regulatory analysis uses the eCFR page displayed as current through October 16, 2026. ^[1] This was checked for the October 2026 report rather than relying solely on the earlier snapshot supplied for research.

The information chain often starts before a flight-specific NOTOC exists. The International Air Transport Association (IATA) documents dangerous-goods declaration data being exported for downstream NOTOC use. ^[5] Its Connect documentation also describes transfer into external systems. ^[6] These interfaces provide a reason to test the entire handoff: a successful upstream data export does not demonstrate that the final aircraft location reached the crew.

LANDING.AERO's editorial perspective here is software integration. The packaged-product comparison concerns NOTOC, load-control and EFB interfaces; the custom-bridge discussion concerns the operator's own information contract. Neither discussion evaluates aircraft loading suitability or replaces an operator's approved procedures. FAA guidance identifies the operator's manual and training revision process as a separate regulatory workstream. ^[3]

The central analytical distinction is document accuracy versus receipt evidence. A current record that nobody can retrieve and a signed record containing a superseded location pose different system questions. Testing should expose both, while leaving the operational response to the operator's designated personnel.

Key Changes: What an Electronic Revision Must Preserve

Loading location makes the document flight-specific

The US content requirement includes the exact loading location of the packages. ^[1] For system design, that means a shipment identifier alone is insufficient to distinguish the information presented before and after a location change. The proposed contract should preserve the source shipment reference and a separate flight-specific location snapshot.

Upstream formats need equally careful interpretation. IATA's XSDG message uses Extensible Markup Language (XML) for electronic dangerous-goods declaration data. ^[5] Its documentation explains that mandatory message-validation fields do not always correspond to data available on the paper declaration. ^[5] A syntactically valid export should therefore be tested separately from the correctness of its transformation into a flight-specific display. The proposed acceptance criterion is that the test can identify where each displayed field originated and who authorized its revision.

Receipt is a separate event

The US loading-person confirmation concerns no evidence of package damage or leakage, including leakage from loaded unit load devices. Separately, PIC information and emergency-response information must remain readily available to the PIC and dispatcher during flight. ^[1] The rulemaking explanation recognizes a notation through an operator computer system as a way to capture receipt confirmation. ^[7] This supports electronic implementation without prescribing the database schema proposed in this report.

The software evaluation should distinguish a transport response, a device download, a document opening and a human receipt action. Those are proposed event categories, not interchangeable evidence. The decisive test is whether the receipt record points to the content that was actually presented. A generic flight-level acceptance flag is difficult to interpret when the content has changed underneath it.

Ground delivery need not be a direct message

PHMSA interpretation 20-0052 explains that making information readily accessible in a flight system can satisfy the dispatcher-information requirement under the stated conditions. It does not require a direct message to the dispatcher. ^[8] An operator can therefore test a ground-access model without assuming that every ground recipient must produce the PIC's form of written receipt.

PHMSA interpretation 22-0009 separately confirms ready access to both documents at departure and intended arrival. ^[2] The corresponding engineering question is whether the designated ground user can find the correct flight and edition through the actual authorized access path. A copy in the flight-deck application is not evidence that this ground path works.

European AOC comparison: future applicability

For a European air operator certificate (AOC) comparison, EASA's March 2026 Air Operations material addresses a dangerous-goods loading-position change through an amended NOTOC given to the commander before departure. (Source: www.easa.europa.eu) It also addresses confirmation of the amendment's receipt and ground access until after arrival. (Source: www.easa.europa.eu) Its explicit applicability date is March 27, 2028. (Source: www.easa.europa.eu)

AMC describes non-binding acceptable means of compliance; it should be distinguished from the underlying implementing rule. (Source: www.easa.europa.eu) The publication-day EASA index listed Part-CAT Issue 2, Amendment 25, associated with ground handling. (Source: www.easa.europa.eu) A later listed regulation, 2026/781, concerns simulator training. (Source: www.easa.europa.eu) These checks found no later change to the cited NOTOC AMC, but do not establish that every possible subsequent instrument has been excluded.

The Source-to-Recipient Information Contract

The proposed contract treats each issued NOTOC as an identifiable information object. The World Wide Web Consortium's W3C PROV model is a useful design reference because it connects data to the entities, activities and people involved in producing it. ^[9] Its primer models a revision as bringing a new document version into existence. ^[10] Neither document establishes an aviation obligation; both help make the proposed evidence intelligible.

The suggested sequence has distinct owners:

• Acceptance source: Preserve the declaration or acceptance-data reference supplied to the downstream system. IATA documents this export boundary. ^[5]
• Flight assignment: Associate the data with the intended flight. Awery's documentation illustrates why this deserves a test: saving dangerous-goods data can plan it on associated air-waybill flights. ^[11]
• Loading confirmation: Record the authorized loading-person confirmation separately from a crew receipt. The distinction follows the US rule's separate provisions. ^[1]
• Document issue: Create an edition identifier and a reproducible rendering. The version relationship is a proposed application of document provenance. ^[10]
• Recipient delivery: Identify the application, recipient role and delivery result. IATA's system-authentication model is relevant to system identity, while human receipt remains a different event. ^[12]
• PIC receipt: Capture the crew action against the presented edition. WinOps's documented acceptance/rejection flow provides one product interface to examine. (Source: www.winops.aero)
• Ground and records handoff: Demonstrate retrieval by the designated ground function and preserve the record chain. PHMSA's airport-access interpretation supplies the ground-access boundary. ^[2]

These owners may share a system, but their evidence should remain distinguishable. A proposed event record contains the flight key, shipment references, edition key, event type, actor, occurrence time, server-recording time, result and exception reference. National Institute of Standards and Technology (NIST) audit controls offer a general reference for event type, time, source, outcome and associated identities. ^[13]

Suggested document states are draft, issued, delivered, receipt pending, received, superseded and exception open. These names are design choices. Their value depends on defined transitions: for example, the proposed model preserves receipt of a superseded edition as historical evidence while requiring the current edition's receipt state to be assessed separately. It should never silently move an old receipt onto new content.

IATA's ONE Record describes shared shipment data through a common model and secured application programming interfaces (APIs). ^[12] Its owner-controlled access model also illustrates why a reference to source data and a retained issued snapshot serve different purposes. ^[12] The operator's design review should identify which information can change at source, which issued content must remain reproducible, and which recipients retain access during an outage.

Implementation Considerations and Process Changes

A change after first crew receipt

The proposed revision transaction begins with the accepted edition and an authorized change event. It produces a new candidate edition, a recorded relationship to its predecessor and a fresh assessment of required recipients. The database should make it possible to reconstruct the content associated with each receipt. W3C's distinction between the original entity and a revision is the underlying engineering reference. ^[10]

Concurrent edits deserve an explicit test. The Internet Engineering Task Force's Hypertext Transfer Protocol (HTTP) semantics specification, Request for Comments (RFC) 9110, describes If-Match as protection against the lost-update problem. ^[14] In a proposed NOTOC interface, an equivalent version precondition can stop a delayed editor from overwriting a more recent issue. The operator should demonstrate the result using its actual interfaces, including products that exchange files rather than HTTP updates.

Recommended invariants for this transaction are:

• Content binding: A receipt identifies the edition and its retained content, rather than only the flight.
• Traceable replacement: The earlier edition remains identifiable after the replacement is issued.
• Separate confirmation: A location revision triggers the operator-defined review of loading confirmation.
• Recipient continuity: Required crew and ground destinations are assessed for the new edition.
• Visible uncertainty: Pending or conflicting evidence has an owner and a documented exception path.
• Human authority: The system presents status and routes work according to the operator's procedures.

These are proposed acceptance criteria. The US rule does not prescribe these state names, identifiers or transaction boundaries. Its receipt requirement supplies the obligation against which the operator evaluates the implementation. ^[1]

Offline EFB and delayed messages

An offline test should begin with a device containing the earlier edition, then introduce a later edition on the ground side. The test asks what each user can actually see and what happens when the device reconnects. FAA's EFB guidance discusses disagreements between EFBs or other flight-deck sources and recommends associated procedures and training. ^[15]

The evaluator should distinguish local action time from server receipt time. A crew action captured offline may be recorded centrally later. A proposed audit design preserves both timestamps and their meaning, rather than treating upload time as the time the person acted. NIST's timestamp control supplies a general reference for system-clock-based audit records. ^[13]

Retries need their own contract. RFC 9110 explains why idempotent methods can be retried after a communication failure. ^[14] A receipt endpoint using another method should explicitly define an equivalent duplicate-handling design; idempotence must not be inferred merely because an API exists. A repeated upload should preserve the original action reference and reveal whether it was already processed.

Failed delivery and procedural recovery

The evaluation should exercise an unavailable device, an expired ground credential, a rejected document and a missed synchronization. The desired software outcome is an intelligible pending or exception state with an accountable recipient. FAA EFB guidance identifies failure procedures and backup considerations as training subjects. ^[15]

The International Federation of Air Line Pilots' Associations (IFALPA) position paper supports electronic NOTOC evolution subject to availability and usability conditions. ^[16] This is an industry position, not a legal requirement. It reinforces the value of testing information availability separately from normal-network delivery.

Recovery procedures must specify what personnel do when the evidence is incomplete. A software supplier should demonstrate how the exception is surfaced and recorded; the operator determines the operational response through its approved procedures and authorization framework. FAA's manual-revision process is relevant where the proposed workflow changes those procedures. ^[3]

Electronic NOTOC Revision Test Matrix

Table 1 translates the proposed contract into a reviewable field, event, recipient and owner matrix. It is an analyst-designed acceptance framework. Its regulatory anchors are the US location and receipt requirements, while its audit structure draws on general provenance and event-record concepts. ^{[1] [7] [9]}

The matrix deliberately separates data validity, delivery evidence, human receipt and record availability. A vendor demonstration that covers one column should not be counted as evidence for all of them. For example, IATA's Connect API establishes a source-data transfer capability, not the loading-person or PIC events in this proposed matrix. ^[6]

The following fault-injection cases make the matrix operationally reviewable without prescribing dangerous-goods handling:

• Late location edit: Change only a synthetic location field after the earlier edition has a recorded receipt.
• Offline flight deck: Retain the earlier edition locally while issuing its replacement centrally.
• Duplicate receipt: Submit the same action twice and inspect the resulting history.
• Out-of-order delivery: Deliver the replacement before the earlier queued document.
• Conflicting editors: Submit changes from clients holding different predecessor editions.
• Crew identity change: Replace the designated recipient and inspect attribution of existing receipt records.
• Ground access loss: Remove a station user's normal access and demonstrate the authorized exception path.
• Archive reconstruction: Retrieve an issued edition and its receipt after routine retention processing.

These cases are proposed software tests, with expected results agreed before execution. Conditional-update and retry semantics provide reusable technical tools for the concurrency cases. ^[14] The evaluator should retain observed results and discrepancies rather than treating an attractive demonstration as acceptance evidence.

Vendor Evaluation Versus a Custom Bridge

Table 2 compares documented interface capabilities, not measured compliance or operational performance. The gaps are questions to demonstrate in the operator's configuration; they do not assert that a vendor lacks the capability.

The distinction between a NOTOC claim and a nearby loadsheet claim matters. A joint signing screen may be useful, but the acceptance test should change the NOTOC location while leaving unrelated weight-and-balance values unchanged. The test then reveals whether the configured relationship between the documents matches the operator's intended procedure. DynamicSource's public workflow is a starting point for that inquiry, not a substitute for it. (Source: www.dynamicsource.se)

An operator-specific custom bridge is relevant when source and destination products exist but their handoff leaves an evidence gap. The bridge's proposed scope is narrow: correlate edition identifiers, route documents, reconcile delivery events and expose an exception queue. Existing products remain responsible for their contracted functions. WinOps documents an external loadsheet-provider interface; that is a reason to examine the precise data contract rather than infer unlimited integration coverage. (Source: www.winops.aero)

Procurement should request a reproducible evidence package:

• Interface contract: Identify field mappings, identities and document ownership at each boundary.
• Revision demonstration: Execute the same synthetic change across every proposed solution.
• Receipt export: Show the actor, edition and time semantics in retained evidence.
• Failure recovery: Demonstrate offline, duplicate and out-of-order cases.
• Archive retrieval: Retrieve content and receipt through the proposed ground and records paths.
• Change ownership: Identify who maintains mappings, procedures and acceptance evidence after an upgrade.

This review found feature descriptions, not a common independent end-to-end revision benchmark. The purchase decision should therefore compare demonstrated outcomes against the same operator-defined tests. Awery's documented ability to deassign dangerous-goods data from a flight supplies another useful source-assignment scenario for that test set. ^[11]

Data Analysis and Evidence

Regulatory numbers are record boundaries, not performance targets

The principal US retention figure is 90 days for PIC information. Shipping-paper copies have separate periods: one year for other hazardous materials and three years for hazardous waste. ^[1] The software specification should identify each record class explicitly and have the operator confirm the applicable policy. A retention label on a combined document is insufficient evidence of how its associated receipt and content can later be reconstructed.

A separate UK comparison illustrates the danger of normalizing unlike periods. UK SPA.DG.110 specifies at least three months after flight completion for its listed dangerous-goods records. ^[18] This is a UK requirement, not a statement of the US or EU rule. Its ground-access provision also identifies relevant flight-operations personnel. ^[18] A calendar-month period should not silently be converted into a fixed number of days in a shared configuration.

The public ICAO page identifies the 2025-2026 Technical Instructions edition as valid through December 31, 2026. (Source: www.icao.int) The amendment index lists Addendum No. 1 dated March 27, 2026. (Source: www.icao.int) These are source-maintenance dates, not evidence that the licensed instructions' detailed global receipt provisions were verified. State variations require separate attention. (Source: www.icao.int)

Synthetic revision timeline (Hypothetical Example)

Table 3 is an invented integration-test sequence. R-A, R-B, the shipment key, locations and elapsed times are synthetic labels. They carry no dangerous-goods handling instruction and establish no regulatory timing allowance.

The useful measurements are the intervals between issue, device availability, human action, central recording and ground retrieval. The table's times are examples, not observed latency or required service levels. Clock-based audit records and explicitly designed retry semantics support measurement quality. ^{[13] [14]}

The reviewed vendor pages do not provide a common test population, comparable latency distribution or independent delivery-success measurement. Their descriptions establish different interface starting points. Bytron documents an auditable flight record, for example, while CHAMP describes a load-plan audit trail. Those claims need different follow-up evidence before they can be treated as comparable NOTOC revision outcomes. (Source: www.bytron.aero) (Source: www.champ.aero)

Implications and Future Directions

An electronic NOTOC audit trail is most useful when it can answer a concrete question: which content did this person receive, and which ground function could retrieve it at that point? A list of timestamps without content relationships cannot answer that question by itself. Provenance provides a general design vocabulary for those relationships. ^[9]

The immediate implementation priority is a shared acceptance contract across cargo acceptance, loading, operational control, flight deck and records. IATA's standardized data-sharing and system-authentication descriptions can help frame the interfaces. ^[12] They do not establish the operator's human acknowledgment procedure, and should not be represented as doing so.

The European transition is a reason to examine revision semantics before procurement is complete. The cited AMC expressly addresses receipt of an amendment, with future applicability in 2028. (Source: www.easa.europa.eu) US teams should retain their own jurisdictional mapping, including PHMSA's distinction between direct messaging and ready access for dispatchers. ^[8] A shared product can support separate configurations without turning different obligations into a single generic acceptance flag.

Questions that remain operator-specific include:

• Applicability: Which materials, exceptions, permits and approvals are relevant to the operator's authorized activities?
• Document boundary: Which records are combined, and which content and receipts remain separately identifiable?
• Authorized change: Who may correct a loading location and issue its replacement information?
• Crew action: What written electronic receipt action is defined in the operator's procedure?
• Ground access: Which named functions can retrieve the current information at the required locations?
• Offline procedure: What does the crew do when available editions disagree or delivery evidence is incomplete?
• Records policy: Which retention periods apply to the document classes and related evidence?
• Oversight route: Which proposed manual, training or EFB changes require acceptance, approval or other coordination?

These questions should be resolved with the operator's responsible dangerous-goods, operations and regulatory personnel. FAA describes the principal operations inspector route for manual and training revisions. ^[3] For a global operation, the complete licensed ICAO text, its amendments and relevant variations require their own review. (Source: www.icao.int) Software supports that process; an AI-generated recommendation or dashboard status is not the operator's authorization decision.

Frequently Asked Questions (FAQs)

Can a NOTOC be electronic in the United States?

Yes. PHMSA interpretation 22-0009 confirms electronic form and also discusses electronic shipping papers. ^[2] An electronic format still needs a defined delivery, access and receipt workflow. The article's proposed state model is one way to test that workflow, not a prescribed federal schema.

Does electronic delivery prove pilot receipt?

The US requirement is a written PIC indication that the information was received. ^[1] A transport response should therefore be assessed separately from the operator's human receipt action. The proposed test binds the latter to the edition presented.

What should happen after a NOTOC location change?

For system evaluation, issue a distinguishable replacement and test its handoff, receipt and ground availability under the operator's procedures. Separately, EASA's future AMC specifically addresses an amended NOTOC after a loading-position change. (Source: www.easa.europa.eu) That AMC is explicitly applicable from March 27, 2028. (Source: www.easa.europa.eu)

Is a digital declaration or API connection enough?

IATA documents XSDG export for downstream NOTOC use and API-based data transfer. ^{[5] [6]} Those are upstream capabilities. The proposed flight-specific test additionally follows the issued content through loading confirmation, crew receipt and records retrieval.

Conclusion

Electronic NOTOC revision control should be evaluated through a traceable change, rather than through the presence of a digital form. The system needs an intelligible relationship between source information, issued content, recipients, human receipt and retained evidence. This report's state model and matrix make that relationship testable without prescribing how dangerous goods should be handled.

The regulatory distinctions remain central. The US workflow includes written PIC receipt and ground-access obligations; PHMSA clarifies that dispatcher access can be provided through an available flight system. ^[8] The European comparison has an explicit future applicability date, which must remain visible in planning and product requirements. (Source: www.easa.europa.eu)

Packaged capabilities can provide useful interfaces, while an operator-specific bridge can address a defined gap between existing systems. Neither choice should be accepted solely from a feature label. The reviewable outcome is a demonstrated revision scenario: the new edition is identifiable, the crew action is attributable, ground access works, earlier evidence remains interpretable and exceptions reach the designated owner.

The operator should retain the test evidence alongside the decisions about procedures, training and authorization. That turns a software selection into an assessable information handoff. The system's role is to support approved procedures and show what happened. Operational authority remains with the people and processes designated by the operator.