INDUSTRY FIELD GUIDE
Simulated air traffic event data for AI evaluation
An estimated event time can persist in a report after a later observed time becomes available.
NAICS 488111 · Air Traffic Control
An estimated event time can persist in a report after a later observed time becomes available. A model summarizing performance needs to recognize both the authority and the timestamp of each source. FAA publishes Aviation System Performance Metrics documentation. It offers a reference for a retrospective, offline benchmark. FAA Aviation System Performance Metrics documentation · FAA ASPM flight-level data
Create a synthetic sequence with an estimate, a revised estimate, and a separately verified actual time. Move one event across midnight and document time zones and how the record dates are assigned. Ask the model to explain any discrepancy and cite which field supports the final timeline. Put an unresolved clock offset in a second example. The task is retrospective data review.
Use authorized public aggregates where permitted or fully fabricated exercise data. Keep controller communications, operational identifiers, facility configuration, security data, and live feeds out of the sample. Never use model output for aircraft separation or live control.
Describe a synthetic aviation timing benchmark
Original Fiund exercise
A verified actual event can cross midnight while remaining distinct from earlier estimates
An offline synthetic aviation-reporting fixture uses invalid event aliases. No controller communication, facility configuration, live feed or aircraft-control action is included.
| Record | Source | What it records |
|---|---|---|
| AES1 | Estimate sequence | Event A estimated day 1 at 23:50 UTC, revised estimate day 2 at 00:10 UTC. Both fields explicitly labeled estimates. |
| AES2 | Verified actual | Original independent event A record: day 2 at 00:20 UTC. Report date rule uses actual UTC event date, not the original schedule date. |
| AES3 | Event B | Actual-like timestamp 00:05 on an unspecified clock, plus estimate day 2 at 00:00 UTC. No verified clock conversion or date assignment. |
Question for the model
Which A time and report date follow from the supplied actual record, and can B's estimate-to-event interval be computed?
Show the reference answer and checks
AES2 supports A's actual day-two 00:20 UTC event and day-two report assignment under the stated rule. AES1's revised estimate is ten minutes earlier, while the original estimate belongs to the prior day; neither is the observed event. AES3 lacks a verified clock and date basis, so B's exact interval cannot be calculated. Keep forecast versions and actual-source authority separate rather than choose a timestamp by appearance or force a cross-midnight subtraction.
- Reporting a stale estimate after a verified actual event is available.
- Ignoring midnight date changes or calculating intervals across an unknown clock basis.
Fields to preserve
- Event and estimate version
- Defines the source chain.
- UTC date/time and event type
- Preserves temporal meaning.
- Report-date rule and unresolved offset
- Supports or limits calculation.
Test another case
Change the report-date rule to a separately defined service day while retaining actual UTC time. Require the assigned report date and actual event date to remain distinct fields.
Use original fabricated records. Exclude control and security information; this retrospective benchmark is never connected to live control.
Discuss a contribution
Describe the sources you control, the task they could support and what has already been checked. Use the existing-data assessment for an archive or the collection brief for a new recording project. The contributor agreement defines Fiund’s licensing authority and compensation. A guide or fictional exercise does not establish an accepted collection or a sale.