AirportOpsEnv

Overview

Air traffic and ground control is a high-stakes scheduling problem with hard rules. Most agent benchmarks reward “good enough” answers. This one punishes protocol violations, such as sending a hijacked plane to a passenger gate, with a zero reward. That makes it a test of whether a model can switch from optimizing throughput to following an emergency procedure.

How it works

Each step, the agent sees a snapshot of the airport. The snapshot covers inbound flights, runway and gate status, fuel levels, time of day, holiday flags, active crises and available ground units. The agent replies with exactly one action: assign_runway, assign_gate, hold, divert, scramble_security, scramble_fire, scramble_medical, close_runway or vacate_runway. The environment updates its state, scores the action and returns the next observation.

The environment has no game UI. It is driven entirely over HTTP, so these are the pages the server provides.

spec: OpenEnv (openenv.yaml)
endpoints: /reset /step /state /score /tasks /health
tasks: 3 (easy, medium, hard)
reward: 0 to 1 per action
deploy: Docker, Hugging Face Space

Where it could break

Domain logic modelled

• Priority hierarchy: Army > Medevac > Government/VIP > Commercial > Cargo. A fuel emergency (under 10 minutes of fuel) overrides all of them, including army flights.
• Five crisis types, each with its own required response sequence:
  • Medical emergency: clear a runway, assign a medical gate, send an ambulance.
  • Bomb threat: route to the isolation bay, halt ground movement, notify security.
  • Hijacking: assign an isolation gate, set use_secure_channel=true, scramble security.
  • Runway fire: issue go-arounds, scramble the fire brigade, close the runway.
  • Fuel emergency: assign a runway immediately.
• Context-aware ETAs: a pre-computed lookup table adjusts taxi and arrival times for rush hour, day of week and public holidays.
• Resources: three runways (one can be under maintenance), eight gates (passenger, cargo, medical, isolation bay) and limited ambulances, fire trucks and security teams.

Three tasks of increasing difficulty

Reward and grading

Every action gets a reward between 0 and 1, built from five components: a priority score, a resource-match score, an ETA score, a crisis-protocol score, and a penalty term for hard violations. Each task also has its own grader that produces a final episode score (exposed at /score). The tests include a regression check that a do-nothing agent can’t game the reward.

Baseline agent

inference.py is an LLM baseline that uses the OpenAI-compatible client, so it works with OpenAI, Hugging Face Inference or any compatible endpoint. It uses a protocol-aware system prompt and logs structured [START], [STEP] and [END] events for evaluation.

Highlights

• Designed a multi-objective reward function with hard-penalty gating for safety-critical violations.
• Built a stateful crisis-protocol engine that tracks multi-step compliance across turns.
• Modelled realistic context: fuel-priority overrides, holiday and rush-hour ETA effects, and maintenance closures.
• Wrote regression tests for reward hacking, a schema mismatch in the ETA table, and unreachable grader logic.
• Containerized and deployed it with a REST API, so any agent or framework can plug in.

Tech stack

• Language: Python 3.11
• API server: FastAPI and Uvicorn, with endpoints /reset, /step, /state, /score, /tasks and /health
• Data modelling and validation: Pydantic v2 for typed Observation, Action and Reward schemas
• Environment architecture: a custom state machine with an event and crisis manager, a pluggable per-task grader system, and JSON-defined scenarios
• LLM integration: the OpenAI SDK, pointed at any OpenAI-compatible endpoint
• Spec and tooling: OpenEnv (openenv.yaml), requests, and unittest for regression tests
• Deployment: Docker (non-root user and a healthcheck) and a Hugging Face Space