{
  "title": "Simulated air traffic event data for AI evaluation",
  "source_page": "https://fiund.com/industries/air-traffic-event-simulation-data",
  "authorship": "Original fictional Fiund editorial exercise. No actual operating records or third-party source assets are included.",
  "example": {
    "title": "A verified actual event can cross midnight while remaining distinct from earlier estimates",
    "context": "An offline synthetic aviation-reporting fixture uses invalid event aliases. No controller communication, facility configuration, live feed or aircraft-control action is included.",
    "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": "Which A time and report date follow from the supplied actual record, and can B's estimate-to-event interval be computed?",
    "answer": "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.",
    "failureModes": [
      "Reporting a stale estimate after a verified actual event is available.",
      "Ignoring midnight date changes or calculating intervals across an unknown clock basis."
    ],
    "fields": [
      [
        "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."
      ]
    ],
    "holdout": "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.",
    "boundary": "Use original fabricated records. Exclude control and security information; this retrospective benchmark is never connected to live control."
  }
}