TSA Real Time Wait Time

The Real Time Wait Time (RTRW) is an innovative solution designed to enhance passenger experience, operational efficiency, and security at airport checkpoints. RTWT standardizes wait time data collection methodologies to provide real-time, predicted, and historical wait times for passengers from the moment they enter the security queue to when they exit the screening area.

By leveraging advanced technologies such as AI-powered analytics, sensors, and predictive modeling, RTWT delivers actionable insights to optimize resource allocation, reduce bottlenecks, and improve transparency for travelers.

Objectives

1. Standardized Data Collection: Establish and maintain consistent methodologies for measuring wait times across all TSA security checkpoints, ensuring accuracy and comparability.

2. Real-Time Monitoring: Provide live wait time updates to passengers and airport operators using technologies such as integrated sensors and cameras.

3. Predictive Analytics: Forecast future wait times based on historical trends, current conditions, and passenger flow data.

4. Enhanced Passenger Communication: Display wait times on digital signage or other media to empower passengers with actionable information.

5. Operational Optimization: Equip TSA and airport administrators with tools to dynamically adjust staffing and checkpoint configurations (i.e., queues) based on real-time and predicted wait times.

RTWT aligns with Section 1922 of the FAA Reauthorization Act of 2018, which mandates the Transportation Security Administration (TSA) to:

• Inform the development and deployment of technology that accurately measures passenger wait times at airport security checkpoints.

• Provide real-time wait time information to passengers to improve transparency and enhance the travel experience.

• Standardize wait time data collection methodologies across airports to ensure consistency and reliability.

This legislative directive underscores the importance of leveraging advanced technologies to improve checkpoint efficiency, enhance the passenger experience, and support TSA’s mission of ensuring secure and seamless travel.

Key Features

• Automated Wait Time Measurement: At a minimum, integration of sensors and/or cameras to monitor passenger movement and calculate wait times.

• Predictive Modeling: Use of machine learning algorithms to anticipate future wait times based on historical and real-time data.

• Passenger-Facing Tools: Real-time wait time updates displayed to digital signage or airport websites.

• Checkpoint Performance Analytics: Detailed reporting for TSA and airport administrators to identify trends, optimize staffing, and improve throughput.

• Alerts and Warning: System generated notifications of projected wait-time threshold breaches to prescribe actions for remediation.

Benefits

• Improved Passenger Experience: Transparency in wait times reduces uncertainty and enhances traveler satisfaction. Provide passengers a consistent wait time experience so that they can plan and know what to expect in terms of the time it will take them to be processed through security checkpoints.

• Operational Efficiency: Real-time insights enable TSA and airport operators to proactively manage resources and minimize delays. Support airports by ensuring that the

RTWT solution meets specific technical requirements that deliver a consistent wait time metric to provide travelers with improved experience.

Implementation and Scalability

RTWT is designed for seamless integration into existing airport infrastructure, with scalable capabilities to support airports of all sizes. By standardizing methodologies and leveraging cutting-edge technology, the solution ensures consistent and reliable data collection across TSA checkpoints nationwide.

System Requirements

For a solution to qualify to support the delivery of the TSA RTWT metrics, the solution shall be capable of properly modeling a TSA security checkpoint and meeting the following requirements:

Real-Time Monitoring

• The system shall detect and monitor individuals entering, exiting, and waiting within checkpoint areas.

• The system shall calculate wait times based on the number of individuals in line, their movement speed, and checkpoint processing rates.

• The system shall analyze crowd density in real-time to identify congested areas.

Sensory Data

• The system may leverage one or multiple types of sensors to automate data collection including but not limited to:

o Digital Closed-Circuit Television (CCTV) o Stereo Cameras o Light Detection and Ranging (LiDAR) o Wi-Fi and Bluetooth scanners o Infrared or other people-counting sensors

• The system shall process data from these sensors using Artificial Intelligence (AI) to monitor passenger movement, queue lengths, and wait-times.

• The solution provider shall make recommendations for sensor placement when installing new devices or augmenting existing infrastructure.

CCTV Provisions

• When leveraging CCTV data, the system shall integrate with existing digital CCTV cameras used for security and surveillance at airport checkpoints.

• The system shall support video recording on a limited basis for the sole purpose of auditing AI metrics.

• Recorded videos shall be accessible for validating the accuracy and performance of AI-driven metrics.

• Follow National Archives and Records Administration N1-560-12-002 Item 6a.

AI Metrics

• The system shall support automated data collection and calculation of all metrics defined in Appendix A: TSA Security Checkpoint Ontology, including passenger throughput, queue density, and wait time accuracy.

• The system shall discern between airport representatives, TSA uniformed workforce, passengers, and other populations to strengthen the accuracy of anonymized data.

Boundary Definition Management

• The system shall provide an operator toolkit to define, visualize, and adjust queue entry and exit boundaries.

• Boundaries shall align with the statutory definition of wait time and allow for dynamic adjustments based on real-time conditions.

Queue Overflow

• The system shall detect when a security queue overflows beyond its defined boundaries.

• The system shall dynamically include the additional passenger wait time in the overflow area in its calculations.

• The system shall notify airport administrators when wait times or crowd density exceed predefined (and configurable) thresholds.

• The system shall detect abnormal activity (e.g., sudden crowd surges) and alert airport personnel.

• The system shall provide recommended adjustments to staffing levels and/or checkpoint operations based on real-time conditions.

Agentic Reporting

• The system shall provide agentic reporting capabilities, to include CSV downloads, that meet specific reporting requirements outlined in Appendix A: TSA Security Checkpoint

Ontology.

Maintenance and Support

• The system shall provide health telemetry, including monitoring uptime, performance, and component status.

• The system shall include self-diagnostic tools to identify and report hardware and software issues.

• The system shall detect, log, and report errors in real time, including sensor malfunctions, data anomalies, and communication failures.

• The system shall allow for remote monitoring and troubleshooting by technical support teams.

• The system shall be designed for rapid service and repair, with accessible components and standardized parts where possible.

• The system shall provide actionable alerts, such as notifications for camera or sensor failures.

• The system shall support secure, scheduled, and automated software updates with rollback capabilities.

• The system shall maintain an operational uptime of at least 99.9% over any given month, excluding scheduled maintenance windows.

System Accuracy

• The system shall deliver wait time and accuracy metrics that meet TSA’s Rates and

Standards reporting requirements.

• Accuracy thresholds shall be configurable and validated by TSA.

Display Builder

• The system shall enable the creation of visual displays for AI metrics for display on

Flight Information Display System (FIDS) and other digital signage, adhering to

Appendix B: TSA Branding Guidelines.

AI Metrics and Application Programing Interface (API)

• The system shall provide API access to real-time and historical AI metrics data.

• APIs shall support integration with TSA and Airport third-party systems, which may include dashboards, applications, ticketing systems or other software.

Agentic Flow Detection

• The system shall dynamically detect open/closed lanes and lane switching (e.g., TSA

PreCheck vs standard or blended lanes).

• The system shall support human validation workflows for lane configuration changes.

Time Synchronization Requirements

• All edge and cloud components shall maintain cryptographically authenticated time synchronization using secure protocols (e.g., authenticated NTP or secure PTP).

• Time synchronization shall ensure consistent timestamps across all system components.

Multi-Tenant Isolation

• The system shall enforce tenant isolation by airport/operator, ensuring data segregation between different airports and operators.

• Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) shall be implemented to support checkpoint-level administration and least-privilege data access.

Historical & Predictive Products

• The system shall generate aggregated historical profiles of passenger flow and wait times

(e.g., by weekday/hour).

• The system shall predict future wait times based on historical trends, current conditions, and flight schedules.

• The system shall integrate with flight schedules to anticipate passenger flow based on departure and arrival times.

• The system shall provide near-term predictions based on historical trends and real-time data.

• The system shall provide recommendations to checkpoint managers for optimizing staffing and line configurations.

Rerouting Guidance Logic

• When multiple checkpoints exist within a terminal, the system shall compute policy-approved rerouting suggestions (e.g., "Checkpoint B likely faster").

• Rerouting guidance shall honor airport policies, accessibility constraints, and suppress advice if it would create unsafe congestion.

Operational Dashboards & Information Technology Service Management (ITSM)

Integration

• The system shall provide dashboards for airport administrators to view real-time and historical data.

• The system shall provide operational dashboards for monitoring data quality, availability, alerts, and Service Level Agreement (SLA) tracking.

• The system shall integrate with ITSM and IT Helpdesk tools for incident, change, and problem workflows, including runbooks.

Identity & Access

• The system shall support federated Single Sign-On (SSO) using protocols such as

Security Assertion Markup Language (SAML) or OpenID Connect (OIDC).

• Granular entitlements shall be enabled for different user roles, such as administrators, deployment managers, and operational users.

Data Retention Controls

• The system shall support configurable retention policies for video image data and aggregated operational data.

• Retention policies shall comply with TSA and airport-specific data governance requirements.

• The system shall not store recorded video or image data for an extended period than what is required to audit AI metrics.

Configuration as Code

• All deployment elements (e.g., infrastructure, applications, services, security policies, and dependencies) shall be defined declaratively as code (e.g., Infrastructure as Code (IaC)).

• IaC definitions shall be version-controlled, peer-reviewed with change approval gates, and continuously monitored for drift detection to ensure alignment between declared and actual states.

Privacy and Security

• The system shall anonymize data collected from sensors and cameras to protect passenger and officer privacy.

• The system shall encrypt all data transmissions to ensure security.

• The system shall restrict access to sensitive data to authorized personnel only.

Scalability

• The system shall monitor multiple checkpoints simultaneously across the airport.

• The system shall handle high passenger volumes during peak travel times without performance degradation.

• The system shall allow for the addition of new sensors, cameras, or checkpoints as needed.

Environmental Adaptability

• The system shall function effectively in both indoor and outdoor checkpoint environments.

• The system shall adapt to varying lighting conditions, including low-light and night-time operations.

• Outdoor components shall be weatherproof and capable of operating in extreme temperatures.

Compliance

• The system shall comply with TSA and DHS regulations for technology used in airport checkpoint environments.

• The system shall adhere to privacy laws.

• The system shall meet accessibility standards for public-facing systems.

TSA Real Time Wait Time Trademark Logo Use

The following sets conditions for the use of the TSA Real Time Wait Time trademark. These conditions ensure that only compliant systems and displays accurately representing TSA Real

Time Wait Time requirements can feature the trademark. The requirements below specify the conditions for use of the TSA Real Time Wait Time logo.

To indicate compliance with the requirements, an airport or 3rd party may display the TSA Real

Time Wait Time logo on any public-facing medium, including but not limited to digital screens, mobile applications, websites, or physical signage (“Public Display”).

Usage Requirement

• The TSA Real Time Wait Time logo shall only be displayed with solutions that meet all requirements as defined within this document.

• The system shall pass TSA compliance testing to verify adherence to the RTWT operational, technical, and reporting standards.

Real-Time Guidelines

• Any Public Display of TSA Real Time Wait Time metrics shall ensure that data is refreshed in real-time, with a refresh rate of less than thirty (30) seconds.

• If real-time updates are not feasible, the Public Display shall include a clear and conspicuous timestamp (date and time) indicating when the wait time metrics were last updated.

• The timestamp shall be prominently displayed and formatted according to Appendix B:

TSA Display Guidelines.

Display Guidelines

• The TSA Real Time Wait Time logo shall be displayed as a complete, cohesive unit, adhering to all formatting, structural, and presentation requirements defined in Appendix

B: TSA Display Guidelines.

• TSA Real Time Wait Time metrics shall not be displayed next to or near any other wait time or related metrics to avoid confusion or misrepresentation.

• The logo and associated word marks shall not be altered, resized disproportionately, or combined with other visual elements in a way that violates TSA’s branding standards.

• Airports and 3rd party solutions shall ensure compliance with Appendix B: TSA Display

Guidelines, as issued and updated by TSA.

Prior Review and Approval

• All proposed designs, mockups, and implementations of TSA Real Time Wait Time metrics and logos on Public Displays must undergo prior joint review and written approval by TSA.

• No Public Display using the TSA Real Time Wait Time logo or metrics shall be launched, published, or otherwise made available to the public without receiving written approval from TSA.

• TSA reserves the right to require modifications to any proposed or existing Public

Display to ensure compliance with these standards.

Remedies for Non-Compliance

• Failure to adhere to these requirements will constitute an infringement on the TSA Real

Time Wait Time trademark.

• Non-compliance may result in damages as deemed appropriate by the United States

Department of Homeland Security (DHS), including but not limited to:

o Revocation of trademark usage rights.

o Financial penalties or legal action.

o Removal of non-compliant Public Displays.

Implementation and Compliance Monitoring

To ensure compliance with the trademark use conditions, the system shall include the following capabilities:

Trademark Compliance Validation

• The system shall include a compliance validation process to verify that all Public

Displays meet the TSA Real Time Wait Time system requirements and Appendix B:

Display Guidelines before deployment.

• The system shall generate compliance reports for TSA review, including:

o Metrics accuracy and refresh rate validation.

o Timestamp display verification.

o Adherence to branding and formatting standards.

Periodic Audits

• TSA or its designated representatives shall have the right to conduct periodic audits of

Public Displays to ensure ongoing compliance with trademark use conditions.

• The system shall provide TSA with access to relevant data and configurations to facilitate these audits.

Non-Compliance Alerts

• The system shall include mechanisms to detect and alert TSA of potential non-compliance with trademark use conditions, such as:

o Metrics refresh rates exceeding 30 seconds.

o Missing or improperly formatted timestamps.

o Unauthorized modifications to the TSA Real Time Wait Time logo or metrics display.

A-1

Appendix: TSA Security Checkpoint Ontology

The ontology defines what it is possible to model within a given operating environment. It consists of the set of concepts that can be described (referred to in the platform as unit classes);

the configuration that is required to describe one of those concepts; the metrics that are measured by those concepts; and the relationships between those concepts. These concepts are then instantiated (in a deployment) to describe the actual operating environment.

The following sections describe:

1. The concepts needed to properly model a TSA security checkpoint, which can then be configured and deployed into any airport in order to collect the metrics described.

2. The reports that will be available on the platform as a result of these data collection activities.

Summary Diagram

Links to Sections

● TDC Queue ● Secondary On-Person Screening Area

● TDC Podium ● X-Ray

● Divest Queue ● Recompose Area

● Divest Table ● Recompose Table

● WTMD Queue ● Secondary Accessible Property Screening Area

● AIT Queue ● Screening Lane

● Walk-Through Metal Detector (WTMD) ● Mod-Set

● Advanced Imaging Technology (AIT) Scanner ● Passenger Screening Flow

● ADA Gate ● TSA Checkpoint

A-2

Ontology Concepts (Unit Classes)

TDC Queue

The queue that passengers wait in to get their travel documents checked.

Configuration

Standard multi-TDC counter queue configuration; details depend on specific scenario (e.g., existence/configuration of overflow areas, thresholds, etc.)

Metrics

Metric Type Description

Passengers number value stream

Number of people in the queue area

Number of people in the queue area, excluding TSA personnel

Predicted wait time number value stream

Prediction of the wait time for a theoretical passenger who joins the queue at the back at the current moment

Observed wait time number event stream

Approximated time actually spent by a passenger entering at the given time (retrospective)

A-3

Travel Document Checker Podium

A podium where an officer processes people to establish their identity before the screening process. There are typically multiple of these per pre-screen queue.

Configuration

Field Type Description

Active Region polygon on single camera

Region containing the area in which passengers stand during processing

Post-TDC Region polygon on single camera

Region containing the area in which passengers stand after being processed by the TDC but before divesting;

must be on the same camera as the above

Tripwire tripwire on single camera

Tripwire that passengers cross when they are done being processed

Post-TDC Area

Capacity number Maximum number of passengers that can fit in the post-TDC area before it is considered full

Metrics

Metric Type Description

Open boolean value stream

Whether or not the TDC podium is available to process passengers

Processing boolean value stream

Whether or not any passengers are in the active region

Blocked boolean value stream

Whether or not the process is blocked (i.e., the associated divest queue can’t hold more passengers);

true if:

● No passenger has crossed the exit tripwire in at least 18 seconds

A-4

● The post-TDC area is full

● There is at least one passenger in the active region

● The condition persists for at least 3 seconds

Stalled boolean value stream

Whether or not the process is stalled (i.e., there is nobody present to process); true if:

● There is nobody in the active region

● The condition persists for at least 3 seconds

State state value stream The state of this TDC podium, decided by the first of these that applies:

1. If the podium is not open, then “closed”

2. If the podium is stalled, then “stalled”

3. If the podium is blocked, then “blocked”

4. Otherwise, “processing”

Transactions transaction event stream

Cycle time for each passenger processed by the TDC;

starts when the passenger enters the active region and ends when the passenger exits the active region

⚠️ The “stalled” condition includes both cases that, based on the data element specification, might be either “idle” or “starving” based on context.

A-5

Divest Queue

The queue that passengers wait in to divest.

Configuration

Field Type Description

Region polygons on multiple cameras

Region containing the areas in which passengers wait to divest

Metrics

Metric Type Description

Passengers number value stream

Number of people in the queue area

Number of people in the queue area, excluding TSA personnel

A-6

Divest Table

The table on which passengers place items during divesting.

Configuration

Field Type Description

Table Region polygon on multiple cameras

Region(s) containing the area on which items to be screened are placed.

Active Passenger

Region polygon on single camera

Region containing the area in which passengers stand while actively divesting at this table

Metrics

Metric Type Description

Items number value stream

Number of items on the table, where an item is any group of objects in a tray

Number of items on the table, where an item is a group of objects in a tray or a bag of some kind (suitcase, duffle bag, backpack, etc.)

Transactions transaction event stream

Simplified divest cycle time for each passenger; starts when the passenger enters the active divest region and ends when the passenger exits the region

Divest cycle time for each passenger; only includes time during which the passenger is actively divesting

(does not include time that the passenger waits to push a tray onto a full conveyor)

Processing boolean value stream

Whether or not anyone is divesting (i.e., within the region)

Whether or not anyone is actively divesting

A-7

Stalled boolean value stream

Whether or not the divest process at this table is stalled

(i.e., the queue feeding it is empty)

Blocked boolean value stream

Whether or not the divest process at this table is blocked (i.e., no passengers are divesting due to lack of available space on the divest table)

State state value stream The state of this divest table, decided by the first of these that applies:

1. If the mod-set is not open, then “closed”

2. If the divest table is stalled, then “stalled”

3. Otherwise, “processing”

The state of this divest table, decided by the first of these that applies:

1. If the mod-set is not open, then “closed”

2. If the divest table is stalled, then “stalled”

3. If the divest table is blocked, then “blocked”

4. Otherwise, “processing”

⚠️ For the purposes of data collection, redivest will generally be considered as an additional transaction, and will be measured via the same methods. (Other unit classes will have some knowledge of the frequency of redivest though; see the sections on the WTMD and AIT

Scanner.)

A-8

WTMD Queue

The queue in which passengers wait to go through the walk-through metal detector.

Configuration

Field Type Description

Region polygon on single camera

Region containing the area in which passengers wait to go through the WTMD

Metrics

Metric Type Description

Passengers number value stream

Number of people in the queue area

Number of people in the queue area, excluding TSA personnel

Transactions transaction event stream

Wait time for each passenger, defined as the time that the passenger spent within the region

A-9

AIT Queue

The queue in which passengers wait to go through the AIT scanner.

Configuration

Field Type Description

Region polygon on single camera

Region containing the area in which passengers wait to go through the AIT

Metrics

Metric Type Description

Passengers number value stream

Number of people in the queue area

Number of people in the queue area, excluding TSA personnel

Transactions transaction event stream

Wait time for each passenger, defined as the time that the passenger spent within the region

A-10

Walk-Through Metal Detector (WTMD)

A screening device that passengers are sent through to detect the presence of metal on their person. This is used to screen most PreCheck passengers and to screen general passengers when the AIT queue is significantly backed up.

Configuration

Field Type Description

Entrance tripwire tripwire on a single camera

Tripwire that a passenger crosses when entering the

WTMD from the divest area

Exit tripwire tripwire on a single camera

Tripwire that a passenger crosses when existing the

WTMD to the recompose area

Metrics

Metric Type Description

Transactions transaction event stream

Transactions including: (1) cycle time for each passenger, defined as entrance-to-exit or entrance-to-reverse-entrance time depending on whether or not they were sent back to re-divest; (2) whether or not the passenger was sent back to re-divest

Also include: (3) whether an alarm was triggered; (4) whether the passenger was selected for USP

Also include: (5) whether or not the passenger was likely WTMD-ineligible

Processing boolean value stream

Whether or not anyone is being processed

Stalled boolean value stream

Whether or not the process is stalled (i.e., the queue feeding it is empty); true if:

● Nobody has entered the WTMD for at least 10 seconds

● The WTMD queue is empty

● The condition persists for at least 3 seconds

A-11

State state value stream The state of this WTMD, decided by the first of these that applies:

1. If the mod-set is not open, then “closed”

2. If the WTMD is stalled, then “stalled”

3. Otherwise, “processing”

A-12

Advanced Imaging Technology (AIT) Scanner

A screening device that passengers are sent through to detect objects on or within their body, as well as a secondary region immediately outside the scanner used for manual inspection of flagged areas. This is the method of screening used for most passengers.

Configuration

Field Type Description

Entrance tripwire tripwire on a single camera

Tripwire that a passenger crosses when entering the

AIT area from the divest area

Exit tripwire tripwire on a single camera

Tripwire that a passenger crosses when existing the

AIT area to the AIT secondary screening area

Post-AIT OPS region region on a single camera

Region immediately after the AIT scanner that a passenger stands in for secondary screening

Metrics

Metric Type Description

Transactions transaction event stream

Transactions including cycle time for each passenger, defined as entrance-to-exit time

Transactions including: (1) cycle time for each passenger, defined as entrance-to-exit time; (2) whether or not secondary screening was performed

(true if the passenger spent more than a specific threshold of time in the secondary screening region);

(3) whether or not the passenger was sent back to re-divest

Also include: (4) whether or not an alarm was triggered, with any related details from the TSE

Also include: (5) information on specific secondary screening activities performed (visual pat-down, non-sensitive-area pat-down, sensitive area pat-down, which specific sensitive area, etc.)

A-13

Processing boolean value stream

Whether or not anyone is being processed

Stalled boolean value stream

Whether or not the process is stalled (i.e., the queue feeding it is empty); true if:

● Nobody has entered the AIT for at least 10 seconds

● The AIT queue is empty

● The condition persists for at least 3 seconds

State state value stream The state of this AIT scanner, decided by the first of these that applies:

1. If the mod-set is not open, then “closed”

2. If the AIT scanner is stalled, then “stalled”

3. Otherwise, “processing”

A-14

ADA Gate

A gate used to pass through empty mobility equipment or passengers who have opted out of standard screening.

Configuration

Field Type Description

Tripwire tripwire on one camera

Tripwire that people/objects cross when using the ADA gate

Metrics

Metric Type Description

Transactions transaction event stream

Transactions consisting of: (1) type of object

(passenger, TSA personnel, wheelchair, stroller) passing through the ADA gate; (2) whether they crossed in the forward or reverse direction

A-15

Secondary On-Person Screening Area

An area in which secondary screenings of passengers are conducted. (This does not include the secondary area immediately following the AIT scanner, only the dedicated secondary on-person screening area.)

Configuration

Field Type Description

Region polygon on one camera

Region containing the area occupied by a passenger during the secondary screening process.

Metrics

Metric Type Description

Transactions transaction event stream

Cycle time for each passenger; begins when the passenger enters the region, and ends when the passenger exits the region

Transactions including: (1) cycle time for each passenger (see definition above); (2) active time, when the TSO is actively engaging with the passenger

Also include information on specific secondary screening activities performed (sensitive area pat-down, which specific sensitive area, etc.)

A-16

X-Ray

A device used to screen accessible property.

Configuration

Field Type Description

Recompose belt region region on one camera

Area before the recompose table that items occupy while waiting to be picked up

Recompose belt capacity number Maximum number of items that the output belt can hold

Suspect belt region region on one camera

Area where suspect baggage waits to be processed for secondary screening

Recompose belt tripwire tripwire on one camera

Tripwire that an item passes when it exits to the recompose belt

Suspect belt tripwire tripwire on one camera

Tripwire that an item passes when it exits to the suspect belt

Metrics

Metric Type Description

Transactions transaction event stream

An event for each item (set of objects on a tray) that exits the x-ray, including whether it went to the suspect belt or the recompose belt

Also handle the case of loose items

Stalled boolean even stream

Whether or not this process is stalled (i.e., the divest belt is empty)

Blocked boolean event stream

Whether or not this process is blocked (i.e., the recompose belt is full, based on the configured capacity)

A-17

Whether or not this process is blocked (i.e., the recompose belt is full, based on the sizes/locations of items)

State state value stream The state of this x-ray, decided by the first of these that applies:

1. If the mod-set is not open, then “closed”

2. If the x-ray is stalled, then “stalled”

3. If the x-ray is blocked, then “blocked”

4. Otherwise, “processing”

A-18

Recompose Area

The area that passengers wait in to recompose.

Configuration

Field Type Description

Region polygons on multiple cameras

Region containing the areas in which passengers wait to recompose

Metrics

Metric Type Description

Passengers number value stream

Number of people in the recompose area, excluding TSA

⚠️ This area is not modeled as a queue because it does not meet the general criteria for a queue

(e.g., it’s not orderly, it’s not necessarily First-In, First-Out (FIFO)-like).

A-19

Recompose Table

The table from which passengers retrieve their items during recompose.

Configuration

Field Type Description

Table Region polygon on one camera

Region containing the area from which items to be screened are retrieved

Active Passenger

Region polygon on one camera

Region containing the area in which passengers stand while actively recomposing at this table

Metrics

Metric Type Description

Items number value stream

Number of items on the table, where an item is a group of objects in a tray or a bag of some kind (suitcase, duffle bag, backpack, etc.)

Transactions transaction event stream

Simplified recompose cycle time for each passenger;

starts when the passenger enters the active recompose region and ends when the passenger exits the region

Also include active time for each passenger; only includes time during which the passenger is actively recomposing (does not include time that the passenger waits for their items, or pushes other people’s items down the table)

A-20

Secondary Accessible Property Screening Area

Configuration

Field Type Description

Table Region polygon on one camera

Region(s) containing the area from which items to be screened are retrieved

Metrics

Metric Type Description

Transactions transaction event stream

Transactions including simplified secondary accessible property screening cycle time; begins when the item is brought to the SAPS table, and ends when the item is removed from the table, either by the passenger or by

TSA personnel

Also include the types of searches done, as determined by which equipment the officer interacts with

Begin cycle time when the bag is removed from the suspect belt and end cycle time when the item is returned to the passenger or abandoned by the officer for a re-scan; also include which of those occurred, and independently how long the passenger waited at the

SAPS table

A-21

Screening Lane

Metrics

Metric Type Description

Passengers number value stream

Number of people in the screening lane

Number of people in the screening lane, excluding

TSA personnel

Open boolean value stream

Whether or not this screening lane is open, based on the presence or absence of passengers and TSA

A-22

Mod-Set

A set of screening lanes (generally one or two) that share on-person screening equipment.

Metrics

Metric Type Description

Passengers number value stream Number of people in the mod-set

Number of people in the mod-set, excluding TSA personnel

Open boolean value stream Whether or not this mod-set is open, based on the presence or absence of passengers and TSA personnel

A-23

Passenger Screening Flow

The entire flow that a passenger could go through. Consists of a single TDC queue, a set of TDC podiums, and a set of mod-sets that process the same group of passengers. Generally, there will be one of these for standard screening and one for PreCheck, and possibly additional for other types of screening (e.g., priority, crew).

Metrics

Metric Type Description

Passengers number value stream Number of people in the flow

Number of people in the flow, excluding TSA personnel

Predicted wait time number value stream Prediction of the wait time + processing time for a theoretical passenger who joins the queue at the back at the current moment

Observed wait time number event stream Approximated queue + processing time actually spent by a passenger entering at the given time

(retrospective)

K9 Active boolean value stream Whether or not K9 screening is active

A-24

TSA Checkpoint

The entirety of a TSA checkpoint. Consists of a set of passenger screening flows.

Metrics

Metric Type Description

Passengers number value stream Number of people in the checkpoint

Number of people in the checkpoint, excluding TSA

A-25

Reporting

The platform leverages the ontology defined above to enable the delivery of a wide range of reports. The below examples will be of primary focus as they line up closely with existing data collection efforts, a variety of other reports will be made available as well.

Global Numbers Aggregate Report

This report summarizes the prorated per-lane measures for a selected period of time. This report will include the following measures:

Measure Dimension Method of Computation

Passenger processing rate pax/hr Total count of recompose transactions (not following the sampling criteria)

Total count of recompose transactions, aggregated and prorated according to the sampling criteria (see below)

Item processing rate items/hr Total count of x-ray transactions, aggregated and prorated according to the sampling criteria (see below)

Items per passenger items/pax Total count of recompose transactions divided by total count of x-ray transactions

Secondary search rate

% Proportion of x-ray transactions exiting to the suspect belt relative to all measured x-ray transactions

For measures depending on the lane being in a pressurized state, the sampling criteria is the following:

● Each lane is evaluated separately for each 15-minute bucket within the selected timeframe.

● The lane is considered in a pressurized state for this report if the x-ray’s “state” metric is

“processing” (i.e., the x-ray is neither stalled nor blocked).

● Rate metrics are only considered at times when the lane is in a pressurized state and the associated screening flow does not have K9 screening active.

A-26

● Any 15-minute sample with more than 300 cumulative seconds of non-included time is discarded.

● Within included samples, all rates are prorated to produce hourly rates.

Passenger Throughput Aggregate Report

This report summarizes the prorated per-mod-set measures for a selected period of time and bucket size. This report will include the following measures:

Measure Dimension Method of Computation

AIT Pax Count pax Total count of AIT scanner transactions

AIT Simple Pax Rate pax/hr Total count of AIT scanner transactions, reported as an hourly rate:

AIT Fully Loaded % % Percentage of the time that the AIT was in the

“processing” state:

AIT Hourly

Utilization-Prorated

Pax Rate pax/hr Hourly rate of AIT passenger processing, prorated to the time spent in the fully loaded state:

AIT alarm rate % by type Proportion of AIT scanner transactions resulting in an alarm relative to all measured AIT scanner transactions, grouped by type

WTMD Pax Count pax Total count of WTMD scanner transactions

A-27

WTMD Simple Pax

Rate pax/hr Total count of WTMD scanner transactions, reported as an hourly rate:

WTMD Fully Loaded

% Percentage of the time that the WTMD was in the

“processing” state:

WTMD Hourly

Utilization-Prorated

Pax Rate pax/hr Hourly rate of WTMD passenger processing, prorated to the time spent in the fully loaded state:

WTMD USP rate % Proportion of WTMD transactions resulting in a USP selection relative to all measured WTMD transactions

ADA Gate Pax Count pax Total count of ADA gate transactions

ADA Gate Simple

Pax Rate pax/hr Total count of ADA gate transactions, reported as an hourly rate:

Appendix B: TSA Real-Time Wait-Time Brand Guidelines Innovation Task Force April 27th, 2026

Consistent Passenger Experience (PX)

Airline app

FIDS Displays Travel Website

Airport Website

Real-Time Wait Time Integration

01. MyTSAApp 02. Live airport RTWT passenger display

Design Principles

Consistency & Recognition Maintain nationwide consistency in visual and functional structure across all airport deployments to ensure a predictable user experience

(UX).

Trust & Reliability The interface must cultivate immediate trust by providing transparency and clarity regarding the data's source and timeliness.

Timeliness The layout must be intuitive, enabling instant recognition and providing granular detail without overwhelming the user.

Trust & Reliability

Information Context A clickable information icon must be placed immediately adjacent to the numeric wait time value or widgets. This ensures crucial context is available on demand, reinforcing recognition without cluttering the primary display.

Logo Integrity

The TSA Real Time Wait Time logo is the visual contract of reliability. It is the symbol of a verified, real-time source.

Therefore, it must only be displayed when the underlying solution meets all defined functional requirements.

Default View Focus The checkpoint widget defaults to displaying the Real Time Wait Time for the Standard Security Screening Queue. This prioritizes the flow for the majority of travelers.

End-to-End Wait Time Clarity The metric must be explicitly labeled as "Real-Time Wait Time" with logo mark to clearly communicate that the number represents the entire process, from queue entry to security exit, including any overflow areas. This removes ambiguity about the wait time number's scope

Principle: The interface must cultivate immediate trust by providing transparency and clarity regarding the data's source and timeliness. This is achieved by ensuring users know what they are seeing and when it was confirmed.

Verified RTWT Widget

Height: 225 pxWidth: 180 px

Checkpoint Name

RTWT Logo

“Liveliness” Indicator

Wait Time

Branding Requirements

A clickable information icon must be placed immediately adjacent to the numeric wait time value or widgets.

The metric must be explicitly labeled as "Real-Time Wait Time" with logo mark to clearly communicate that the number represents the entire process, from queue entry to security exit, including any overflow areas.

Consistency & Recognition

Principle: Maintain nationwide consistency in visual and functional structure across all airport deployments to ensure a predictable and instantly recognizable user experience (UX).

Core Layout Principle

The application interface must maintain a consistent visual and functional structure across all national deployments, regardless of the physical airport configuration (single vs. multiple terminals/checkpoints).

This ensures the experience is predictable for the passenger.

User Specific Optionality

The application provide persistent filtering options to allow users to switch the wait time to other queue types (e.g., PreCheck, CLEAR, etc.).

This empowers the passenger to personalize the default view based on their type.

Queue Type Visual Order

When presenting the full list menu of queues for a checkpoint, the visual order to align with:

1. Primary: Standard Security Screening

2. Secondary: TSA PreCheck

3. Tertiary: Other specialized queues

Standardized Unit

Wait times must always be presented in the concise min unit (e.g., "5 min" vs. "5 minutes").

User Specific Optionality / Standardized Unit

Standard

Wait times must always be presented in the concise "min" unit

30 min+ Wait Time Dark Mode

All standard UI elements must utilize the defined TSA Green (#5e9732)

All standard UI elements must utilize the defined TSA Blue (#005288)

TSA PreCheck

Timeliness

Principle: The layout must be intuitive, enabling instant recognition of options and guiding passengers efficiently through the airport environment.

Data Timeliness

Wait time metrics must be refreshed in less than thirty (30) seconds to validate the "real-time" claim. The display should also include a liveliness indicator ( an animated pulse) to make it immediately clear to users that the data is actively updating in real time.

Degraded State

If the 30-second refresh cadence fails to be met over 5 minutes, the system must immediately signal degraded quality to the end users.

Queue Status Management

Closed or unavailable lanes must display corresponding message to reflect on-ground reality.

Disruption State Display

If Real-Time Wait Time refresh rate is not met, the app must display a clear timestamp (date and time) of the last update with “Unavailable” to clearly signal that the number is not currently available.

Visualizing Timeliness

Queue Status Management

Data Timeliness Disruption State Display

If refresh rate is not met for over 15m the app must display a clear timestamp of the last update with

“Unavailable.”

Closed or unavailable lanes must display corresponding message to reflect on-ground reality.

Wait time metrics must be refreshed in less than thirty

(30) seconds to validate the

"real-time" claim.

Degraded State

If the 30-second refresh cadence fails to be met over 5m, the system must signal degraded quality.

Memorandum of Agreement Regarding Access to and Usage of Wait Time Data

To enhance mission performance, TSA is committed to promoting a culture founded on its values of integrity, innovation, and team spirit.

MEMORANDUM OF AGREEMENT

AMONG

THE DEPARTMENT OF HOMELAND SECURITY,

TRANSPORTATION SECURITY ADMINISTRATION

AND

AND

REGARDING ACCESS TO AND USAGE OF WAIT TIME DATA

I. PARTIES

The parties to this Memorandum of Agreement (MOA) are the U.S. Department of Homeland Security (DHS), Transportation Security Administration (TSA) and

II. AUTHORITIES

This MOA is authorized under the Aviation and Transportation Security Act, specifically 49 U.S.C. § 114(m), as well as Section 1922 of Public Law 115-254 (49 U.S.C. § 44901 note) “Real-Time Security Checkpoint Wait Times.”

III. PURPOSE AND SCOPE

(“Solution Provider”) will enable The DHS, TSA and secure, owned and operated by (“Airport” or “Aircraft Operator”) wait time data transmission from the Solution Provider’s database to a secure TSA repository, in accordance with DHS policies. For the purposes of this agreement “wait time data” is defined as the average measure of all wait times from the end of the TSA security screening checkpoint (“Checkpoint”) queue up to the Travel Document Checker. Some airports may have more robust solutions which measure wait times up to the Walk- Through Metal Detectors, Advanced Imaging Technology units, or after the passenger collects their property and exists the TSA Checkpoint. To extent practicable, the Airport/Aircraft Operator should share the additional wait time data with TSA. The Airport/Aircraft Operator and TSA have a mutual interest in monitoring queues within the and .

2 | P a g e designated Checkpoint at the Airport and have agreed to provide access to and share wait time data in order to enable the delivery of real-time and historical Checkpoint data.

IV. AIRPORT/AIRCRAFT OPERATOR RESPONSIBILITIES

The Airport/Aircraft Operator will operate, manage, and maintain the Solution Provider continuously and provide access to wait time data appropriately.

A. Providing information. The Airport/Aircraft Operator owns, operates, manages, and maintains its Wait Time System, which may utilize proprietary or commercial sensors and/or data analytic techniques (e.g., artificial intelligence, machine learning, data modeling, etc.) at various locations throughout the Airport. The Airport/Aircraft Operator will designate a Technical Point of Contact (POC) that will work with TSA’s Information Technology team to implement the Application Programming Interface (API), applicable security controls, and conduct any troubleshooting as required. Data formats and schemas, API keys, and system endpoints may be requested or provided by TSA to configure the API as needed.

B. New equipment. The Airport/Aircraft Operator will be responsible for any necessary networking equipment to ensure secure connections and cover the costs associated with the installation of this equipment by an installer selected by the Airport/Aircraft Operator. Upon installation, this new equipment shall be owned and managed by the Airport/Aircraft Operator.

C. Maintaining equipment. The Airport/Aircraft Operator will maintain, repair, and restore any added or existing Solution Provider equipment associated with this Agreement. Maintenance and repairs shall be performed in a reasonably timely manner and with reasonable effort to facilitate equipment continuous operation. Airport/Aircraft Operator will promptly notify TSA of any service outage lasting greater than 4-hours.

D. Connectivity. The Airport/Aircraft Operator will provide sufficient internet connectivity to ensure the wait time data is sent via TSA’s API to the TSA repository without delay.

E. Providing data access. The Airport/Aircraft Operator will provide authorized TSA personnel and the TSA API with access to Airport/Aircraft Operator wait time data as determined reasonable by the Airport/Aircraft Operator.

F. Support. The Airport/Aircraft Operator will provide support during business hours to authorized TSA personnel regarding implementation of TSA’s API and accessing wait time data from the Solution Provider platform. In addition, if existing network devices need to be reconfigured to enhance the operations of the API, the Airport/Aircraft Operator will support these efforts without significant delay and without compromise to the Airport’s/Aircraft Operator’s existing security program.

G. Improving the passenger experience. TSA will make the determination if a solution complies with the Wait Time definition and provide official branding as appropriate. For technology solutions that comply with the Wait Time definition listed in Pub. L. 115–254, div. K, title I, § 1922, Oct. 5, 2018, 132 Stat. 3561 (49 U.S.C. § 44901 note) the Airport/Aircraft Operator will apply “TSA Real Time Wait Time” branding to Solution Provider metrics that are displayed in public view or on publicly accessible digital content (e.g., apps, websites, digital displays, etc.). The “TSA Real Time Wait Time” branding may only be applied to technology

3 | P a g e solutions which comply with the statutory requirements and with TSA’s Real Time Wait Time requirements (to be published to industry at a later date).

V. TSA RESPONSIBLITIES AND USE

A. Provide IT Infrastructure. TSA will design, build, and assess a back-end repository/database and front-end user interface to view the Solution Provider wait time data. TSA will also design, build, and assess and a custom Application Programming Interface (API) for the Solution Provider to configure for wait time data transmission. TSA’s API will call for Solution Provider wait time data and execute the data transmission. TSA will provide the Solution Provider with an open Application Programming Interface (API) to facilitate wait time data transmission to a publicly accessible and secure repository identified by TSA.

B. Access. TSA will have access to live and archived wait time data associated with the Checkpoint.

C. Provide Project Management Oversight. TSA will function as the project manager to implement the IT infrastructure and interconnectivity required to fulfill this agreement. Should TSA become aware of an unplanned service outage or equipment failure, TSA will notify the Airport/Aircraft Operator so that timely service restoration can be coordinated among the Parties. TSA will operate, manage, and maintain the API through the term of the agreement.

The API will not require routine maintenance support from Airport/Aircraft Operator personnel but will require the Airport/Aircraft Operator to maintain its cybersecurity posture.

D. TSA will apply “TSA Real Time Wait Time” branding to Solution Provider…