Airports and airfields
The full Airfield Autonomy Operational Framework for the world's busiest airport.
Hartsfield-Jackson moves more passengers than any airport on earth. Before a single vendor conversation, the airport needed something almost nobody in aviation had: a written, complete statement of what an autonomous vehicle must satisfy to operate on its airfield. That became 214 requirements, and it is now the foundation everything else is built on.
- Client
- Hartsfield-Jackson Atlanta International Airport
- Environment
- Airfield and airport campus
- Engagement
- Airfield Autonomy Operational Framework
- Foundation
- 214 requirements
Start with requirements, not vendors
Airports are approached constantly by autonomy vendors. Those conversations almost always start with a vehicle demonstration, which means the airport is being asked to evaluate an answer before anyone has written down the question.
ATL did it in the correct order. We built the requirements first: 214 of them, each one a specific, testable statement of what a system has to satisfy to operate on that airfield. Written down, owned by the airport, and independent of any manufacturer.
That single decision changes the buyer's position entirely. A vendor evaluation stops being a judgment call about a demonstration and becomes an exercise in checking a system against a list the airport already controls.
Application-specific and domain constants
The requirements split into two kinds, and the split is the part worth stealing.
Domain constants are true of the airfield no matter what vehicle arrives or what job it is doing. The environment, the traffic, the weather, the surfaces, the radio coverage, the rules of the movement area. These are written once and inherited by every future application.
Application-specific requirements change with the job. A baggage tug, an autonomous mower and a system detecting debris on a runway share an airfield but not a task, and each carries obligations the others do not.
Structuring it that way means the airport is not starting from zero for its second application, or its fifth. The constants carry forward. Only the application layer gets rewritten. Most airports that skip this end up redoing the whole analysis for every new use case, and pay for it every time.
What the requirements support
With the foundation in place, the rest of the framework has something to attach to.
The safety work maps autonomous ground vehicle operations onto the four pillars of the airport's existing safety management system rather than standing up a parallel process nobody would maintain. The hazard register runs to 23 identified hazards, each with initial and residual risk ratings and the mitigation controls behind it, aligned to FAA risk assessment methodology.
The operational domain analysis defines what the airport intends to operate, then tests candidate systems against it to find where a manufacturer's stated envelope does not cover the conditions the airfield actually presents. That gap is where most deployments quietly fail, usually about eighteen months in.
All of it is managed in Mission Command, our deployment platform, so every requirement, hazard, decision and approval carries a traceable record back to its source.
Why it matters
The deliverable is not a recommendation deck. It is a defensible position: this is what we require, this is what we intend to operate, this is the envelope the technology actually covers, these are the hazards, these are the controls, and here is the evidence for each one.
That is the difference between an airport that can authorize a deployment and an airport that keeps commissioning studies.
Write the requirements before you meet the vendors. Everything downstream is easier, and the ones you skip you pay for twice.