Airport Ops

Overview

Built for the Meta Online Hackathon. The challenge was to use OpenAI’s environment tooling to create a setting where a model could learn real-world applications. AirportOpsEnv is an OpenEnv-compliant environment where an AI agent acts as an Airport Ground Operations Controller — deciding which planes land on which runways, which gates they park at, and in what order, while simultaneously responding to real-time crisis events like hijackings, medical emergencies, and runway fires.

The idea: an airport management system as a reinforcement learning environment. Hackathon currently ongoing.

Why This Domain

The environment simulates a task that real humans do every single day at every major airport in the world — which is what makes it score high on real-world utility. A model trained here is learning a workflow that airport controllers actually operate, not a synthetic toy.

The Core Loop

Every “step”, the agent receives a snapshot of the airport’s state — which flights are waiting, what resources are free, what time it is, whether a crisis is active — and responds with exactly one action: assign a runway, assign a gate, hold a flight, divert one, or scramble an emergency unit. The environment updates its state, scores the action, and returns a reward. This continues until all flights are handled or the episode times out.

Airport Resources

Three physical resource types to manage:

• Runways — three, some landing-only, some takeoff-only, some dual-use. One may be under maintenance in harder scenarios.
• Gates — eight, split into passenger terminal gates, cargo bays, medical gates, and an isolation bay used exclusively for security threats. The agent must match the right flight to the right gate type.
• Ground units — ambulances, fire trucks, and security teams, each available in limited numbers and dispatched as part of crisis response.

Priority Hierarchy

Not all flights are equal:

Rank	Flight Type
1	Army / Defense
2	Medevac / Medical
3	Government / VIP
4	Commercial
5	Cargo

One critical override: a fuel emergency with less than 10 minutes remaining jumps to the top of the queue, above even army flights. Based on real aviation protocol, and the single most important rule the agent must internalize — the grader specifically tests it.

Time of day and day of week also matter. Rush hour on a Monday morning means longer taxi times and tighter runway availability; a public holiday means worse ETAs, cargo backlogs held by the night curfew, and reduced staff. These are encoded in a pre-computed ETA lookup table, and assignments are scored partly on whether the agent picked the fastest available option given those conditions.

Crisis System

The crisis layer is what makes the environment genuinely hard — and genuinely novel. Crises activate at specific steps within a scenario and require the agent to switch from optimization mode into protocol-following mode. Five types:

Medical emergency — clear the nearest runway regardless of who’s queued ahead, assign a medical-type gate, and dispatch an ambulance. Failing any of these within one step drops the protocol score significantly.

Bomb threat — route the flight to the isolation bay, halt nearby ground movement, and notify authorities in order: security → fire → police. The airport does not shut down. Sending a bomb threat flight to a passenger terminal is a hard penalty: total reward zero.

Hijacking — squawk 7500. Assign a remote stand far from the terminal and other aircraft, and critically set use_secure_channel: true — real hijack protocol requires all communication outside public channels, and the grader explicitly checks this flag. Scramble security. Normal operations continue for all other flights.

Runway fire — issue a go-around to every aircraft on final approach within one step, dispatch the fire brigade, close the runway in state so it can’t be used until cleared, and reroute all pending landings to alternate runways.

Fuel emergency / Mayday — less than 10 minutes of fuel overrides every other priority. Assign the closest available runway immediately, even if that means instructing a taxiing aircraft to vacate. Making a Mayday flight wait even one step is a hard penalty.

Tasks

Three scenarios with a clear difficulty progression:

Task	Difficulty	Flights	Crises
task1	Easy	5	1 medevac
task2	Medium	8	Fuel emergency + bomb threat
task3	Hard	15	Hijacking + runway fire

• Task 1 — five flights request landing at the same time; one medevac declares an emergency mid-approach. Tests basic priority understanding and one straightforward protocol response.
• Task 2 — eight flights during Monday morning rush hour with one runway under maintenance and three gates occupied. A commercial flight under 10 minutes of fuel outranks the army charter (fuel wins); a cargo plane has a bomb threat. Resource scarcity and competing priorities.
• Task 3 — fifteen flights on Diwali morning just after the night curfew lifted, with a hijacking and a runway fire active simultaneously. Both protocols must be executed independently, without letting one interfere with the other, while still processing all fifteen flights. The scenario that separates good models from great ones.

Scoring

Every action gets a reward between 0.0 and 1.0 made up of five components:

Component	Weight	What it checks
priority_score	30%	Priority hierarchy respected for the action
resource_match_score	25%	Right gate/runway type assigned to the right flight
eta_score	20%	Assignment efficiency given time of day and holiday context
crisis_protocol_score	15%	Correct crisis response sequence followed
penalty	10%	Deducted for hard rule violations

Some violations zero the total reward outright — sending a hijacked plane to a passenger terminal, for example. Rewards are computed at every step (not just episode end), so the agent gets continuous learning signal.

Architecture

A single Python package with three logical layers:

• State layer — state.py, models.py (typed Pydantic models: Observation, Action, Reward)
• Environment layer — env.py, openenv.yaml (OpenEnv interface: reset(), step(), state())
• Grader layer — graders/task1.py, task2.py, task3.py (deterministic scoring)

Plus a FastAPI wrapper (app.py) exposing /reset, /step, /state, /health, a mandatory baseline inference agent (inference.py) that drives the environment through the OpenAI client, and a Dockerfile for containerized deployment to Hugging Face Spaces.

Build Status

Per the build plan in the repo (phases.md):

• Phase 1 (foundation — models, data, state machine): complete
• Phase 2 (core env — events, graders, AirportOpsEnv): complete
• Phase 3 (API & inference — FastAPI wrapper, baseline agent): complete
• Phase 4 (deployment — openenv.yaml, Dockerfile, README): built, but openenv validate, a clean Docker run, and the HF Space deployment still pending

Open Problems / What’s Next

• Scenario data — the task scenario JSONs are stubs so far; to be populated fully in later steps.
• Validation — openenv validate has not been run against the submitted environment yet; Docker build and HF Space deployment also pending.
• Hackathon still ongoing — this page will track the outcome as it lands.

Code & Links

• Repo: github.com/Ronit9320/Airport_Ops
• idea.md — the full concept write-up
• architecture.md — complete build manual and scoring spec
• phases.md — build phases and status
• MIT licensed