DRAFT - Attachment 02 - Exhibit B - LSX-ICD.pdf

i

For Official Use Only

Customs and Border Protection Non-Intrusive Inspection Division

Interface Control Document Between Large-Scale X-Ray (LSX) Equipment and CBP Cloud Version 1.0.0

11/17/2025 ii

Table of Contents

1. Introduction

1.1 Overview

1.2 UFF Data

1.3 Data Source

1.4 CBP Cloud

2. Assumptions, Constraints, and Risks

2.1 Assumptions

2.2 Constraints

2.3 Risks

3. Interface Overview

3.1 Payload and Timing Requirements

3.1.1 File Naming

3.1.2 Timeliness

3.1.3 Security and Integrity

3.2 Data Requirements

UFF Events 5

3.3 3.3 XSD Extension

3.3.1 Supplemental Events

Digital Signature

3.4 XML File Validation

4. Detailed Interface Requirements

4.1 Technical Interface Requirements

System Interoperability Requirements

5. Implementation Examples

5.1 Example Event Timeline

5.2 Example Data Flow Diagram

6. Appendices

Appendix A: Record of Changes

Appendix B: Glossary

Appendix C: QR Code and RFID (Gen-2) Data Payload

Appendix D: UFF XSD Extension iii

List of Figures

Figure 1 QR Example

Figure 2 Target Event for LPR Correction

Figure 3 Analysis Event

Figure 4 Provision as a Supplemental Event

Figure 5 Finalization

Figure 6 Health

Figure 7 Event Log

Figure 8 Config

Figure 9 UML Sequence Diagram

List of Tables

Table 1: Record of Changes

Table 2: Glossary

Table 3: QR Code and RFID Data Payload

1. Introduction U.S. Customs and Border Protection (CBP) maintains a fleet of Non-Intrusive Inspection (NII) equipment, including large-scale x-ray scanners for cargo and conveyance scanning. To maximize the utility of NII equipment, systems must often be integrated with ancillary systems at ports of entry (POEs). For example, entry and exit gate arms, radio frequency identification device (RFID), QR code readers, and license plate readers (LPRs) are often integrated with U.S. government POE data systems. These integrations support effective screening operations and minimize undue impact to legitimate entry into the U.S. by improving data availability and enabling the automation of some actions. Moving inspection data and metadata rapidly from equipment at the POE to the CBP cloud in near real-time is key to this effort.

Data and metadata elements that must be ingested from the POE include x-ray images, vehicle identification information, information about CBP officer actions, system health and availability information. Information generated by and stored in original equipment manufacturer (OEM) systems may be in disparate formats, and therefore a common interface must be specified to ensure that downstream applications can effectively utilize it. This specification heavily references the Unified File Format (UFF) 3.0+ standard as a basis and adds minor extensions and descriptions for how the structures defined in UFF3.0+ should be populated. These details are described in section 3.2. The UFF specification documents from the World Customs Organization (WCO) can be found at:

https://www.wcoomd.org/en/topics/facilitation/instrument-and-tools/frameworks-of-standards/safe_package/documents-on-the-uff.aspx This interface control document (ICD) specifies the interface requirements participating systems must meet. It describes the concept of operations for the interface, defines the message structure and protocols that govern the exchange of data, and identifies the communication paths along which data is expected to flow.

For each interface, the ICD provides the following information:

• A description of the format and protocol for data exchange

• A general description of the interface

• Assumptions where appropriate

• Frequency of data exchange

1.1 Overview

This section describes the systems that comprise the means to transfer data from x-ray imaging systems to CBP’s cloud. Subsequent sections describe in detail the interfaces and controls between these systems, their data requirements, and their support requirements.

1.2 UFF Data

All data contained within this document shall adhere to the UFF 3.0+ format, inclusive of CBP-produced extensions for port data, and structured in accordance with Section 3.2 prior to transmission to the CBP cloud. Any reference to "UFF" herein pertains specifically to UFF 3.0+ specification document: UFF 3.0.

https://www.wcoomd.org/en/topics/facilitation/instrument-and-tools/frameworks-of-standards/safe_package/documents-on-the-uff.aspx https://www.wcoomd.org/en/topics/facilitation/instrument-and-tools/frameworks-of-standards/safe_package/documents-on-the-uff.aspx https://www.wcoomd.org/-/media/wco/public/global/pdf/topics/facilitation/instruments-and-tools/tools/safe-package/nii-guidelines-2018/uff-300technical-specificationsen.pdf?db=web

1.3 Data Source

In this specification, “Data Source” refers to the entity that is implementing this specification and producing compliant data packages for the downstream consumer. Data collected and sent by the data source will include NII x-ray scans and associated metadata and imagery from ancillary systems.

The x-ray system may be a high, medium, or low energy system and may be fixed or mobile. In addition to the x-ray imaging system, sensors may be present that gather vehicle/trip identifying information (RFID, LPR, QR code reader, bar code reader, and others). If this information is present, it will be included in the data transferred to CBP’s cloud.

The data source is responsible for packaging UFF and other metadata into the format described in Section 3.2 Data Requirements. The data source shall generate UFF events as soon as images and metadata become available. The files shall be retained on data source equipment in accordance with CBP regulations.

1.4 CBP Cloud

The CBP cloud serves as the central repository and processing hub for data collected from data sources, including x-ray imaging systems, analysis platforms, and various sensors. Its primary function is to ensure that the data is securely transmitted, stored, and accessed by authorized downstream consumers. The cloud platform is designed to receive and handle data in UFF format, with extensions for port-specific requirements. Occasionally a data source may be required to pass data to the CBP Cloud through a third-party system. In these situations, the data source and the third-party systems shall both comply with this ICD.

2. Assumptions, Constraints, and Risks

2.1 Assumptions

• NII X-ray data to CBP cloud as the main scope: While the data format and pipeline described herein may be used for additional screening equipment such as radiation portal monitors (RPMs) or for alternative scenarios in the future, the main use case covered at present is x-ray inspection at the land border POEs, specifically bringing x-ray data to the CBP cloud in a timely, robust, and fault-tolerant way.

• General guidance vs as-built: This specification provides a set of general guidelines, focusing on the data source to CBP cloud interface. Details for specific port/implementation may vary from the examples documented herein. Such deviations will be described in “as-built” documentation.

• Data Source transforms data into UFF format before sending to CBP cloud. If transformation fails or data cannot be transformed, a notification of this data will still be passed to CBP cloud.

2.2 Constraints

• NII equipment must have network connectivity to the CBP cloud. Network connectivity must have sufficient bandwidth to transmit all payloads sent by the data source.

2.3 Risks

• Internet connectivity. The pipeline design assumes that a CBP Inter-Connection Point (ICP) circuit will be used as the primary connection. If one is not available, a commercial internet service provider (ISP) will be used. Mobile configurations may use a cellular ISP with a hardware firewall as required. The data pipeline requires an internet connection to post data to CBP cloud and is not intended to operate fully offline. Data sources must have a system in place to re-transmit stored data if an attempt to send it to the CBP cloud fails. The duration for which the data is stored will be determined by CBP's data retention policy.

3. Interface Overview This section describes the technical details of the interface between NII equipment at POEs and the data pipeline in CBP cloud. Specific hardware and software implementations may vary from port to port. Specific interfaces for interfacing with CBP applications to manage the transfer of data will be provided prior to implementation efforts depending on the nature of the deployment.

3.1 Payload and Timing Requirements

3.1.1 File Naming

Files produced from this interface will comply with the UFF specification.

3.1.2 Timeliness

A payload will be sent whenever a new UFF event occurs to ensure prompt data delivery. Any new data shall be included in a new UFF event with a unique identifier. All events related to the same land-border crossing should have the same UFF ID so that they can be linked upon arrival in the CBP cloud. Unrelated events should have unique UFF IDs.

To facilitate CBP operations, data will be delivered to the CBP cloud as soon as possible, including data acquired prior to x-ray images. Identifying or supplemental data such as scene cameras, license plate images or reads, RFID reads, or QR codes must be transmitted in an appropriate UFF event as soon as acquired by the Data Source.

Specific timing allowances for each operation will be dependent on contract for each installation and port operational requirements. To meet these requirements, no UFF data shall be delayed while under review by an officer. If officer review results in corrections to the data, this will be delivered as a new UFF event.

Section 5 Implementation Examples contains an example of this data delivery timeline.

3.1.3 Security and Integrity

Communication with this interface will be within an isolated network at a POE, a CBP managed enterprise virtual network, or within a government-controlled cloud environment. When outside of an isolated network, Transport Layer Security (TLS) will be used to secure the connection between all components. Any passwords used for access control must be compliant with CBP password complexity requirements. When an API is used, TLS client certificates will be used for authentication where supported, and firewall access control lists (ACLs) will be used to allow access to appropriate systems.

3.2 Data Requirements

The section below describes requirements for populating UFF files with NII data for this interface.

UFF Events

3.2.1 UFF ID

All UFF packages must use the UFF base element and have a valid UFF ID in the Id element. Note that the UFF XSD does not mark this as a required field, but it is required for compliance with this

ICD.

3.2.2 Scan Event

The Scan event contains the information captured from any scan of the target, to include both optical character reader (OCR) and X-ray scans. Scan events may contain one or more images from the data source. Any additional vendor proprietary files will be appended to the event using the OutputFile element.

3.2.3 QR and RFID Data

QR and RFID scans are a common element of CBP NII data. The UFF specification does not contain a natural place for this data, so it will be transmitted using AdditionalInformation elements in a Scan event. Images of the QR code or other images captured at the time of scan will be appended to the event using the OutputFile element. The following example shows what a scan event containing QR or RFID would look like:

<?xml version="1.0" encoding="UTF-8"?> <UFF xmlns="http://tempuri.org/UFF3.0.xsd"> <Id>8f3a9c2e-1b4d-4e7a-9c3f-1d8e2a1b7c7d</Id> <Scan> <EventId>431d9fd0-6eca-41f6-aec5-da9ce57ac3a4</EventId> <ScannerCaseId>65bba194-6903-4c66-b16a-8785d91d71cf</ScannerCaseId> <XraySystem> <Identifier>0334</Identifier> <Manufacturer>ACME Inspection Systems</Manufacturer> <ModelName>QR Reader</ModelName> <SerialNumber>QRR12345</SerialNumber> </XraySystem> <TimeStamp>2025-10-29T14:30:17.428Z</TimeStamp> <AdditionalInformation> <Item> <Key>QRCode</Key> <Value>V01 MYTRIPIDENTIFICATION54321 20190430 US TXAAA1234 MXCOAABC3637</Value> </Item> </AdditionalInformation> <OutputFIle> <FileId>8f3a9c2e-1b4d-4e7a-9c3f-5d8e2a2b7e9a</FileId> <URI>event_431d9fd0-6eca-41f6-aec5-da9ce57ac3a4/qr-code-1-8f3a9c2e-1b4d-4e7a-9c3f- 5d8e2a1b7d9a.jpg</URI> <Type>Photo</Type> </OutputFile> <OutputFIle> <FileId>8f3a9c2e-1b4d-4e7a-9c3f-5d8e2a2b7d9a</FileId> <URI>event_431d9fd0-6eca-41f6-aec5-da9ce57ac3a4/driver-1-8f3a9c2e-1b4d-4e7a-9c3f- 5d8e2a1b7d9b.jpg</URI> <Type>Photo</Type>

</OutputFile> </Scan>

</UFF>

Figure 1 QR Example

3.2.4 Target Events

Target Events contain additional or corrected identification information. For example, OCR license plate corrections or pre-arrival identification data.

<?xml version="1.0" encoding="utf-8"?> <UFF xmlns="http://tempuri.org/UFF3.0.xsd"> <Id>8f3a9c2e-1b4d-4e7a-9c3f-1d8e2a1b7c7d</Id>

<Target> <EventId>5c0b3c5d-5a6b-43c2-88a8-3615b25f9cde</EventId> <Operator> <LoginName>SJO1234</LoginName> </Operator>

<InspectionSystem> <Identifier>8765</Identifier> <Manufacturer>ACME Inspection Systems</Manufacturer> <ModelName>ACME Operator Workstation</ModelName> <SerialNumber>AOW-2024-00123</SerialNumber> <Country>US</Country> </InspectionSystem>

<Comment>Manual correction of license plate reading - automatic OCR misread character due to damaged plate. Operator verified correct plate number through physical inspection and cross-reference with vehicle registration documents.</Comment>

<TimeStamp>2025-10-29T14:33:33.555Z</TimeStamp>

<Vehicle> <FrontPlateNum>ABC1234</FrontPlateNum> <RearPlateNum>ABC1234</RearPlateNum> <VehicleType>Truck</VehicleType> <AdditionalInformation> <Item> <Key>LPR_Previous_Subdivision</Key> <Value>RX</Value> </Item> <Item> <Key>LPR_Corrected_Subdivision</Key> <Value>TX</Value> </Item> <Item> <Key>LPR_Corrected_Country</Key> <Value>US</Value> </Item> <Item> <Key>LPR_CorrectionReason</Key>

<Value>Damaged/Obscured Plate - Manual Verification Required</Value> </Item> </AdditionalInformation> </Vehicle>

</Target>

</UFF>

Figure 2 Target Event for LPR Correction

3.2.5 Analysis Events

Analysis events contain notes and recommendations (hold/release) created by officers and algorithms.

If created by an officer, this event is generated after the officer has evaluated the NII case. Image overlay data (i.e. the shapes drawn on an image by an officer or algorithm) shall also be included at this stage in the form of an annotation.

To better support directional annotations such as arrows, BoundingBox elements Top, Left, Bottom and Right will always be interpreted as Y1, X1, Y2, X2. In the case of arrows specifically, (X1, Y1) will be the start of the arrow and (X2, Y2) the point.

<UFF xmlns="http://tempuri.org/UFF3.0.xsd"> <Analysis> <Comment>Manual image inspection revealed suspicious anomalies in cargo area requiring secondary inspection</Comment> <TimeStamp>2025-10-24T14:45:20-06:00</TimeStamp> <Assessment>Image</Assessment> <Result>Found</Result> <Annotation> <AnnotationId>a1b2c3d4-e5f6-7890-abcd-ef1234567890</AnnotationId> <Description>Suspicious Dense Object</Description> <Comment>High-density anomaly detected in rear cargo area, inconsistent with declared goods. Appears to be concealed within electronic equipment shipment.</Comment> <Shape>Rectangle</Shape> <BoundingBox> <Top>245</Top> <Left>512</Left> <Bottom>398</Bottom> <Right>687</Right> </BoundingBox>

Figure 3 Analysis Event

3.3 XSD Extension

Some actions taken upon a case, such as a case assignment to a specific analyst workstation at a port, are necessary to capture for this interface but are not specifically addressed in the UFF data specification. This section describes requirements for capturing these actions and when they should be utilized. Examples of the structures of these payloads can be found in Appendix D:.

3.3.1 Supplemental Events

Supplemental events are an event type added in the XSD extension produced for this interface to capture additional information such as the provisioning and finalization of cases. The Supplemental event will be populated with the AdditionalInformation element as defined in the UFF specification.

Note that the AdditionalInformation element is available for the other events as well. These fields can be used when there is a small amount of information that fits the purpose of the other event types but does not fit well into any of the pre-defined event contents. Supplemental events should be used for cases where a large structure or one that does not fit another event type is sent.

3.3.2 Provisioning

A Provision is generated in response to the determination of where a case is going next/to whom it is being provisioned, for example the specific officer or analyst workstation. This data will be captured within a Supplemental event, depicted below.

The AdditionalInformation element in a provision event will contain at least the following:

• An <Item> element with <Key> of EventName and <Value> of Provision, to indicate the event type being transmitted

• An <Item> element with <Key> indicating where the case is being provisioned to. Examples are LawEnforcementConsole, HashId, and EmailAddress. At least one of these three must be present. HashId is preferred for human actors, when available. The <Item> corresponding to this key will be the data of this type, for example, the HashId of the analyst to whom the case is being provisioned.

If the Provision event is created from the actions of a person logged into a CBP system (e.g., a supervisor assigning cases to officers for review), the Hash ID or other relevant identifier for that user will be transmitted via the <Operator> element, as shown in the example below.<…> <Supplemental xmlns="http://tempuri.org/UFF3.0.xsd"> <EventId>d3fd03a8-99e4-42b5-9939-1c47956b5ed1</EventId> <Operator> <LoginName>SJO1234</LoginName> </Operator>

<InspectionSystem> <Identifier>8765</Identifier> <Manufacturer>ACME Inspection Systems</Manufacturer> <ModelName>ACME Operator Workstation</ModelName> <SerialNumber>AOW-2024-00123</SerialNumber> <Country>US</Country> </InspectionSystem>

<TimeStamp>2025-10-29T14:31:33.555Z</TimeStamp>

<AdditionalInformation> <Item> <Key>EventName</Key> <Value>Provision</Value> </Item> <Item>

<Key>Version</Key> <Value>1.0</Value> </Item> <Item> <Key>LawEnforcementConsole</Key> <Value>04</Value> </Item> <Item> <Key>HashId</Key> <Value>DOG5872</Value> </Item> </AdditionalInformation> </Supplemental>

Figure 4 Provision as a Supplemental Event

3.3.3 Finalization

The finalization is generated in response to officer/analyst action that indicates that no further events should be expected—the officer/analyst has completed work on the case. If no officer/analyst action is available to indicate that work has been completed, the finalization payload should be sent after a period determined based on standard port operations. This data will be captured within a Supplemental event, described below.

<Supplemental xmlns="http://tempuri.org/UFF3.0.xsd"> <AdditionalInformation> <Item> <Key>EventName</Key> <Value>Finalize</Value> </Item> <Item> <Key>Version</Key> <Value>1.0</Value> </Item> <Item> <Key>Action</Key> <Value>Finalize</Value> </Item> </AdditionalInformation> <RelatedEvents>a3f01d84a-99e4-4205-9939-1c4795d05ed2</RelatedEvents> </Supplemental>

Figure 5 Finalization

3.3.4 Health and Status Data

To capture health and status data for NII equipment, the StatusEvent has been created. Three elements, Health, EventLog, and Config, have been added to capture specific types of information.

Element descriptions can be found below, and the StatusEvent extension can be found in the XSD extension in Appendix D:. Any system health status and configuration data not regularly reported per scan shall be reported separately using the StatusEvent element.

3.3.4.3 Health

The Health element of Status event shall be used to provide a periodic snapshot of key system metrics. These metrics are expected to be monitored and documented such that system operators are aware of acceptable ranges and abnormal thresholds. Message timing can vary from minutes to hourly depending on the measurement.

<Status xmlns="http://tempuri.org/UFF3.0.xsd"> <Description>Scheduled health monitoring check - all systems operational</Description> <Impact>None - Routine health check</Impact> <Health> <HealthData> <EventDatetime>2025-10-22T19:00:00Z</EventDatetime> <OperatingMode>LIVE</OperatingMode> <DeviceType>X-Ray Generator</DeviceType> <DeviceID>XRG-001</DeviceID> <RequestCode>HEALTH-CHECK-001</RequestCode> <RequestingAgency>CBP</RequestingAgency> <CommunicationStatus>Configured and Communicating</CommunicationStatus> <OperationStatus>OPERATIONAL</OperationStatus> <HealthStatus>Full Functionality</HealthStatus> <MessageType>Nightly Health Check</MessageType> <MessageSeverity>Note</MessageSeverity> <HealthDetail HealthName="Temperature" HealthValue="42.3" HealthValueUnits="celsius" /> </HealthData> </Health> </Status>

Figure 6 Health

EventLog EventLogs shall be used to transmit system occurrences triggered by a condition. Event severity could scale from informational (scan starting), to non-critical warnings (UPS battery charging, QR image blurry, time synchronization failure), to critical errors (system offline, UVIS not operational) It is important for the system to have detection techniques to monitor status and send event information to CBP cloud to ensure, to the extent possible, that the system is operating as expected.

<Status xmlns="http://tempuri.org/UFF3.0.xsd"> <Description>Event log containing system warnings and errors</Description> <Impact>Minor - System continues operation with reduced functionality</Impact> <EventLog> <EventLogData> <EventDatetime>2025-10-22T20:15:30Z</EventDatetime> <OperatingMode>LIVE</OperatingMode> <DeviceType>X-Ray Generator</DeviceType> <DeviceID>XRG-002</DeviceID> <EventID>EVT-20251022-001</EventID> <EventSeverity>Warning</EventSeverity>

<EventCategory>X-Ray System</EventCategory> <EventSubcategory>Temperature</EventSubcategory> <EventCode>XRAY-TEMP-HIGH</EventCode> <EventDescription>X-ray generator temperature approaching upper threshold.

Current temperature: 65°C, threshold: 70°C. System continues to operate normally but monitoring required.</EventDescription> <EventUser>system</EventUser> </EventLogData> </EventLog> </Status>

Figure 7 Event Log

Config The Config element of the StatusEvent shall be used to communicate system settings. Config information shall communicate any system settings that are important to monitor for continued system operation.

<Status xmlns="http://tempuri.org/UFF3.0.xsd"> <Config> <ConfigurationData> <EventDatetime>2025-10-22T21:00:00Z</EventDatetime> <OperatingMode>LIVE</OperatingMode> <DeviceType>X-Ray Generator</DeviceType> <DeviceID>XRG-003</DeviceID> <ConfigurationParameter ConfigName="BeamEnergy" ConfigValue="9" ConfigValueUnits="kv"/> <ConfigurationParameter ConfigName="WarningTemperature " ConfigValue="70" ConfigValueUnits="celsius"/> <ConfigurationParameter ConfigName="ShutdownTemperature" ConfigValue="85" ConfigValueUnits="celsius"/> </ConfigurationData> </Config> </Status>

Figure 8 Config

Digital Signature All system health, configuration and other potentially sensitive data being transmitted via this StatusEvent (an extension of BaseEvent) can make use of the DigitalSignature (DigSign) implemented in the UFF base specification.

3.4 XML File Validation

CBP requires both compliance with this specification and compliance with the UFF XSD and provided extension of the UFF XSD.

Data provided to CBP cloud should be validated by using stand-alone, off-the-shelf validation tools to check xml data against the XSD schema files provided. For example, xsd.exe from Microsoft (Microsoft 2022) provides one-time command line validation of xml files based on a schema.

Integrated development environments, such as Microsoft Visual Studio, JetBrains IDEA, or Eclipse, also include tools for validating xml files against a schema file during software development.

Freely available xml libraries for common programming languages also provide programmatic xml validation from a schema during software development.

When using tools to validate data for this interface, it is important to ensure that the extension in Appendix D: is used in addition to the base UFF XSD.

4. Detailed Interface Requirements

4.1 Technical Interface Requirements

System Interoperability Requirements The following functional requirements describe important details about the information NII equipment shall provide to CBP via the data transfer methods described in this document.

Deployment-specific Value Management An application shall be provided by the NII equipment vendor which allows the user to set parameters that are used for filling in deployment-specific metadata values in messages to be transmitted to CBP cloud. For each UFF event transmitted, the Identifier value within the InspectionSystem/XraySystem must be configurable. Values for this field will be provided by CBP dependent on deployment details. Each node which produces UFF event data is expected to have a separate identifier, so configuration management software must be able to manage multiple values and mapping to their sources. Identification codes for officer/analyst workstations shall be included.

Time Support Real-time clocks on the data processing equipment will be maintained by synchronizing with a time authority, such as a Network Time Protocol (NTP) (preferred) or a GPS receiving device. Locally provided time services, such as those maintained on a cellular/LTE system, can be inconsistent and unreliable, and shall not be used, as they may be subject to drift.

Scanning equipment will also incorporate a real-time clock. That clock shall be synchronized to the NII equipment or file monitoring system clock, e.g., via a virtual NTP service on the NII equipment or file monitoring system.

Resynchronization of the NII equipment system clock shall occur no less frequently than once every 24 hours.

5. Implementation Examples

5.1 Example Event Timeline

The following is a listing of the different events (Scan, Target, Analysis, Provision, Finalization) as part of an example scanning timeline. Details for a specific port/implementation are expected to vary from the examples documented herein and will be documented separately in the as-built documentation. Figure 9 UML Sequence Diagram provides a visual view of this timeline.

1. Vehicle approaches scanner and front plate is read via OCR.

2. ID information is transmitted to NII equipment.

3. ID Scan event is created and transmitted to CBP cloud.

4. Driver presents paperwork to QR scanner

5. ID information is transmitted to NII equipment.

6. ID Scan event is created and transmitted to CBP cloud.

7. Vehicle enters x-ray scanner.

8. Scan is complete.

9. Scan image is transmitted to NII equipment.

10. Xray Scan event is generated and sent to CBP cloud.

11. Vehicle exits scanner and back plate is read via OCR.

12. ID information is transmitted to NII equipment.

13. ID Scan event is created and transmitted to CBP cloud.

14. Case is provisioned to an officer/analyst and Supplemental Event (Provision) is created and transmitted to CBP cloud.

15. Officer/analyst receives image and ID information.

16. (If applicable) NII equipment places request for case-related information to be sent to officer/analyst workstation.

17. Officer/analyst makes any manual corrections needed to automated data capture (LPR, etc.).

18. A Target event is created containing manually updated fields and sent to CBP cloud.

19. Officer/analyst enters adjudication and notes on analyst workstation UI.

20. Officer/analyst clears case from the analyst workstation UI.

21. An Analysis event is generated containing disposition and disposition notes. NOTE: image overlay data (i.e. the shapes drawn on an image by an officer) shall be included when the disposition is made.

22. NII equipment determines that exam has concluded (officer/analyst input).

23. (In absence of concluded scan, 2-hour window passes.)

24. Supplemental Event (Finalization) payload is generated and sent to CBP cloud.

If the disposition is that the scan was faulty and the vehicle needs to go back through, the new scan will be associated with the original scan using the RelatedDatasets element in the UFF specification.

5.2 Example Data Flow Diagram

The following figure depicts a sequence-based view of the events as a UML sequence diagram.

Important: This diagram represents an idealized/example port. Details for a specific implementation may vary from this example.

Figure 9 UML Sequence Diagram

The UML Sequence Diagram illustrates one example of a series of events that can occur during a land-border crossing. The events must be communicated in compliance with the timing requirements outlined in 3.1. Example UFF files for the events listed in Figure 9 above (in order top-bottom):

- example_uff3_scan_lpr_front.xml example_uff3_scan_ lpr_front.xml

- example_uff3_scan_qr[rfid].xml example_uff3_scan_ qr.xml example_uff3_scan_ rfid.xml

- example_uff3_xray_scan.xml example_uff3_xray_ scan.xml

- example_uff3_scan_lpr_back.xml example_uff3_scan_ lpr_back.xml

- example_supplemental_provision.xml example_suppleme ntal_provision.xml

- example_uff3_algorithm_analysis.xml example_uff3_analy sis.xml example_uff3_algor ithm_analysis.xml

- example_uff3_target_lpr_correction.xml example_uff3_targe t_lpr_correction.xml

- example_ supplemental_finalize.xml example_suppleme ntal_finalize.xml

6. Appendices

Appendix A: Record of Changes

Table 1: Record of Changes

Version Number Date Author/Owner Description of Change

2.0 10/31/2025 Customs and Border Protection

(CBP)

Updates for generalizing document for future pipeline operations.

2.0.1 11/17/2025 Customs and Border Protection

(CBP)

Clarify descriptions of Analysis and Provision events, expectations around configurable data elements, and data re-transmission.

Appendix B: Glossary

Table 2: Glossary Term Acronym

Access Control List ACL

Application Programming Interface API

Common Integration Platform CIP

U.S. Customs and Border Protection CBP

Common Internet File System CIFS

Global Positioning System GPS

Interface Control Document ICD

Internet Connection Point ICP

Internet Service Provider ISP

License Plate Reader LPR

Non-Intrusive Inspection NII

Non-Intrusive Inspection Division NIID

Network Time Protocol NTP

Optical Character Recognition OCR

Original Equipment Manufacturer OEM

Port of Entry POE

Quick Response Code QR

Radio Frequency Identification Device RFID

Radiation Portal Monitor RPM

Server Message Block SMB

Secure File Transfer Protocol SFTP

Transport Layer Security TLS

Unified File Format UFF

Unified Modeling Language UML

Extensible Markup Language XML

Appendix C: QR Code and RFID (Gen-2) Data Payload

The format for the data payloads for both QR code and RFID are identical, consisting of up to 64 alphanumeric characters as specified in the March 2020 US Customs and Border Protection ACE Truck Manifest QR Specifications Guide (https://www.cbp.gov/document/guides/ace-truck-manifest-qr-specifications-guide). The format specification is reproduced here for quick reference.:

V01 MYTRIPIDENTIFICATION54321 20190430 US TXAAA1234 MXCOAABC3637

1 2 3 4 5 6

1234567890123456789012345678901234567890123456789012345678901234

Table 3: QR Code and RFID Data Payload

Columns Data Element Notes

1-3 Data layout version number “V01”

4 Separator character Space character. (ASCII 0x20)

5-29 Trade-assigned trip ID number

Trip ID can be entered with fewer than 25 characters. In such case, the field shall be right-padded with spaces. Note that the first four characters of the trip ID represent the shipment company.

30 Separator character Space character. (ASCII 0x20)

31-38 Estimated arrival date in yyyymmdd format Not necessarily the current date.

39 Separator character Space character. (ASCII 0x20)

40-41 License plate 1 country ISO-3166 country code. Typically, “US,” “CA,” or “MX.”

42-44 License plate 1 administrative unit

ISO-3166-2 Subdivision code. For US and Canada, where the state/province codes are 2 letters, the first character shall be the space character. (That is, state abbreviation is right-justified in the three-character field.) Mexican estados have three-letter abbreviations.

45-51 License plate 1 plate number

Seven characters reserved. If fewer than 7 characters, right-pad with spaces.

52 Separator character Space character. (ASCII 0x20)

53-54 License plate 2 country Fill with space characters, if none.

55-57 License plate 2 administrative unit See above, under “License plate 1 administrative unit.”

Columns Data Element Notes

58-64 License plate 2 plate number Fill with space characters, if none.

Appendix D: UFF XSD Extension

To capture the various types of data produced at a POE, an extension was created for use in this interface. XML validation tools should be pointed at this in addition to the base UFF XSD.

XSD Extension for LSX NII (in the text box at the bottom of this appendix as well)

LSXICD.xsd

Summary of the changes made by this extension:

• Identifier and SerialNumber are mandatory fields of the InspectionSystem element instead of optional

• Config, Health and Event elements added as part of a new StatusEvent to better capture details of these types of logs o Config: Capture current parameters of the system. A StatusEvent with this element can be used to send notification of configuration changes of a system to CBP Cloud.

o Health: Capture current health data of the system. A StatusEvent with this element can be used to regularly send system health data to the CBP Cloud.

o EventLog: Capture important logs from the system. A StatusEvent with this element can be used to send important system logs to the CBP Cloud.

• SupplementalEvent type added for other types of data that do not fit neatly into the base UFF spec (see section 3.2.1.3 for use cases with QR and RFID data)

Example messages:

- example_status_config.xml example_status_con fig.xml

- example_status_eventlog.xml example_status_eve ntlog.xml

- example_status_health.xml example_status_hea lth.xml

LSXICD:

<?xml version="1.0" encoding="utf-8" ?>

<xs:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/UFF3.0.xsd" xmlns="http://tempuri.org/UFF3.0.xsd" xmlns:mstns="http://tempuri.org/UFF3.0.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:redefine schemaLocation="UFF3.0.xsd">

<!-- Update InspectionSystem to require Identifier and SerialNumber for CBP NII use -->

<xs:complexType name="InspectionSystem">

<xs:complexContent>

<xs:restriction base="InspectionSystem">

<xs:sequence>

<xs:element minOccurs="1" name="Identifier" type="xs:string">

<xs:annotation>

<xs:documentation>Identifier of the system at site-name. Required for CBP NII.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="Manufacturer" type="xs:string">

<xs:annotation>

<xs:documentation>Manufacturer of the system.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="ModelName" type="xs:string">

<xs:annotation>

<xs:documentation>Model of the system.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element minOccurs="1" name="SerialNumber" type="xs:string">

<xs:annotation>

<xs:documentation>Serial number of the system. Required for CBP

NII.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:choice minOccurs="0">

<xs:annotation>

<xs:documentation>Address or country where the system was when the event occurred.</xs:documentation>

</xs:annotation>

<xs:element name="Country" type="CountryCode"/>

<xs:element name="Address" type="Address"/>

</xs:choice>

<xs:element minOccurs="0" name="Location" type="GeoLocation">

<xs:annotation>

<xs:documentation>Geolocation of the system (last known location or location when the event occurred).</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:restriction>

</xs:complexContent>

</xs:complexType>

</xs:redefine>

<!-- StatusEvent for CBP NII health monitoring -->

<xs:complexType name="StatusEvent">

<xs:complexContent>

<xs:extension base="BaseEvent">

<xs:sequence>

<xs:element name="Vendor" type="Company"/>

<xs:element name="TimeStamp" type="xs:dateTime"/>

<xs:element name="Description" type="xs:string"/>

<xs:element name="Impact"/>

<xs:element minOccurs="0" name="Config" type="Config">

<xs:annotation>

<xs:documentation>Configuration data is an important part of health monitoring. Calibration data, software versions, and system settings can be important for continued system operation.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="Health" type="Health">

<xs:annotation>

<xs:documentation>Health data provides periodic snapshots of key system metrics for monitoring system operators and abnormal thresholds.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element minOccurs="0" name="EventLog" type="EventLog">

<xs:annotation>

<xs:documentation>EventLogs transmit system occurrences triggered by conditions. Severity scales from informational to critical errors (system offline, UVIS not operational).</xs:documentation>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

<!-- Define custom Supplemental Event type for CBP NII -->

<xs:complexType name="SupplementalEvent">

<xs:annotation>

<xs:documentation>Defines a supplemental event for CBP NII. Used to capture additional information that does not fit within standard event types.</xs:documentation>

</xs:annotation>

<xs:complexContent>

<xs:extension base="BaseEvent">

<xs:sequence>

<xs:element minOccurs="0" name="RelatedEvents" type="xs:string">

<xs:annotation>

<xs:documentation>Other UFF Events related to this one.</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

<xs:element name="Status" substitutionGroup="Event" type="StatusEvent">

<xs:annotation>

<xs:documentation>Element used to reference a status event.</xs:documentation>

<xs:element name="Supplemental" substitutionGroup="Event" type="SupplementalEvent">

<xs:annotation>

<xs:documentation>Element used to reference a supplemental event.</xs:documentation>

<!-- Health monitoring base type -->

<xs:complexType abstract="true" name="healthBase">

<xs:sequence>

<xs:element maxOccurs="1" minOccurs="1" name="EventDatetime" type="xs:dateTime">

<xs:documentation>The UTC date and time the configuration changed or when the configuration message was generated.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="0" name="OperatingMode">

<xs:annotation>

<xs:documentation>The operating mode of the Device or System when the message was generated. Examples: SIMULATED, LIVE</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="SIMULATED"/>

<xs:enumeration value="LIVE"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element maxOccurs="1" minOccurs="1" name="DeviceType" type="xs:string">

<xs:annotation>

<xs:documentation>A short device type identifier. E.g. ControlBox, Camera, Xray.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="1" name="DeviceID" type="xs:string">

<xs:annotation>

<xs:documentation>An identifier for the unique device. The device ID should be unique for a particular system.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="0" name="ComponentType" type="xs:string">

<xs:annotation>

<xs:documentation>Use ComponentType and ComponentID fields to identify a particular component. e.g. Detector</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="0" name="ComponentID" type="xs:string">

<xs:annotation>

<xs:documentation>An identifier for the component. The Component ID should be unique for a particular device.</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

<!-- Configuration monitoring type -->

<xs:complexType name="Config">

<xs:sequence>

<xs:element maxOccurs="unbounded" minOccurs="1" name="ConfigurationData">

<xs:complexType>

<xs:complexContent>

<xs:extension base="healthBase">

<xs:sequence>

<xs:element maxOccurs="unbounded" minOccurs="1" name="ConfigurationParameter">

<xs:annotation>

<xs:documentation>ConfigurationParameter captures key value pairs for the Configuration message content.</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:attribute name="ConfigName" type="xs:string" use="required">

<xs:annotation>

<xs:documentation>Configuration name for a name/value pair.

Name values should be unique for a given device or component.</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute name="ConfigValue" type="xs:string" use="required">

<xs:annotation>

<xs:documentation>The value for the key/value pair. All values are considered strings for simplicity and flexibility.</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute name="ConfigValueUnits" type="xs:string" use="optional">

<xs:annotation>

<xs:documentation>SI units should be used when applicable.

If unit-less, leave null. e.g. millimeters, volts</xs:documentation>

</xs:annotation>

</xs:attribute>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:element>

<!-- Event logging type -->

<xs:complexType name="EventLog">

<xs:sequence>

<xs:element maxOccurs="1" minOccurs="1" name="EventLogData">

<xs:complexType>

<xs:complexContent>

<xs:extension base="healthBase">

<xs:sequence>

<xs:element maxOccurs="1" minOccurs="1" name="EventID" type="xs:string">

<xs:annotation>

<xs:documentation>A unique identifier for the event. Should be unique for a given system.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="1" name="EventSeverity">

<xs:annotation>

<xs:documentation>Critical Error, Error, Warning, Note</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="Critical Error"/>

<xs:enumeration value="Error"/>

<xs:enumeration value="Warning"/>

<xs:enumeration value="Note"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element maxOccurs="1" minOccurs="1" name="EventCategory" type="xs:string">

<xs:annotation>

<xs:documentation>Pre-defined category values. e.g. Time

Synchronization, UVIS, QR, LPR, Networking</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="0" name="EventSubcategory" type="xs:string">

<xs:annotation>

<xs:documentation>Details that further categorize the category.

e.g. SystemOccupancyDecision</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="0" name="EventCode" type="xs:string">

<xs:documentation>A unique string for the event type for tracking occurrences over time.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="1" name="EventDescription" type="xs:string">

<xs:annotation>

<xs:documentation>Description for the event. e.g. DB ERROR, Failed to run query, system offline.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="0" name="EventUser" type="xs:string">

<xs:annotation>

<xs:documentation>Name for the user involved with the event, if any.</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:element>

<!-- Health reporting type -->

<xs:complexType name="Health">

<xs:sequence>

<xs:element maxOccurs="unbounded" minOccurs="1" name="HealthData">

<xs:complexType>

<xs:annotation>

<xs:documentation>A HealthReport captures 1 or more HealthDetail elements with key/value pairs for health message content.</xs:documentation>

</xs:annotation>

<xs:complexContent>

<xs:extension base="healthBase">

<xs:sequence>

<xs:element maxOccurs="1" minOccurs="0" name="RequestCode" type="xs:string">

<xs:annotation>

<xs:documentation>Optionally captures a request reference code.</xs:documentation>

<xs:element maxOccurs="1" minOccurs="0" name="RequestingAgency" type="xs:string">

<xs:annotation>

<xs:documentation>The requesting agency. Example:

CBP</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="1" name="CommunicationStatus">

<xs:annotation>

<xs:documentation>Communication status determines how much information can be gathered from the device or component.</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="Configured and Communicating"/>

<xs:enumeration value="Configured and Not Communicating"/>

<xs:enumeration value="Not Configured"/>

<xs:enumeration value="Unknown"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element maxOccurs="1" minOccurs="1" name="OperationStatus" type="xs:string">

<xs:annotation>

<xs:documentation>The operating status when the message was generated. Examples: OPERATIONAL, MAINTENANCE, OFFLINE</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="1" name="HealthStatus">

<xs:annotation>

<xs:documentation>The health status for a device.</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="Full Functionality"/>

<xs:enumeration value="No Functionality"/>

<xs:enumeration value="Partial Functionality"/>

<xs:enumeration value="Unknown"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element maxOccurs="1" minOccurs="0" name="MessageType" type="xs:string">

<xs:documentation>Assists with categorizing messages for reporting. E.g. Nightly Health Check, 10 Minute Ping</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="1" minOccurs="1" name="MessageSeverity" type="xs:string">

<xs:annotation>

<xs:documentation>Severity label for the message. e.g. Unknown, Note, Warning, Error.</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element maxOccurs="unbounded" minOccurs="1" name="HealthDetail">

<xs:complexType>

<xs:attribute name="HealthName" type="xs:string" use="required">

<xs:annotation>

<xs:documentation>Health message name for a name/value pair.

Names should be unique for a given device or component.</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute name="HealthValue" type="xs:string" use="optional">

<xs:annotation>

<xs:documentation>The value for the key/value pair. All values are strings for simplicity and flexibility.</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute name="HealthValueUnits" type="xs:string" use="optional">

<xs:annotation>

<xs:documentation>SI units when applicable. If unit-less, leave null. e.g. millimeters, volts.</xs:documentation>

</xs:annotation>

</xs:attribute>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:element>

</xs:schema>

Appendix E: Example LSX ICD connection to CBP NII Middle Tier

A system can connect to the service through the CBP NMT (NII Middle Tier) API or a Messaging Topic depending on the integration pattern. When using the CBP NMT API, requests are sent through an intermediary layer that handles business logic, security and data transformation before communicating with the Frontdoor service. Alternatively, integration via a Messaging Topic enables asynchronous communication, where the data is published to topic in real time for high-throughput, event-driven processing. While also sending the UFF X-ray images to a S3 bucket for real-time processing.

Example JSON:

"S3FilePath": [ "incoming/MesssageID/2025-09-15/UFF_ID/EVENT_ID.uff" "BucketName": "bucket-name", "MessageCreationDatetime": "2025-09-15T22:49:44.3478808Z", "MessageType": 2, "MessageID": "ExampleID", "UFFEventID": "UFF_ID", "MessageVersion": "1.0", "MessageType": 1

(The UFF File must be uploaded the “bucketName” listed above for the Frontdoor to process the images)

The CBP NMT API accepts a POST request with the same JSON message that would be sent to a Messaging topic. Consequently, the UFF files must also be posted to an S3 bucket. The business logic remains consistent in both scenarios—API and Messaging.

APPENDIX F: ENCRYPTING SENSITIVE

INFORMATION

Sensitive information, such as system health information, may be encrypted by using the AdditionalInformation element. Information must be provided to CBP on how to decrypt this information once it is received. The example below demonstrates this in a Health StatusEvent.

o example_status_health_encrypted.xml example_status_hea lth_encrypted.xml

3.4 XML File Validation

6. Appendices