Rule-based stand allocation: one policy the whole operation runs on

#

TL;DR

Every airport already has an allocation policy. It lives in the experience of the people running the apron, which makes it fast, accurate and impossible to hand over.

Allegra RMS gives that policy a form the system can act on: constraints that block, preferences that guide, and a record behind every decision. The result is one policy that holds on every shift, a plan that survives a disrupted morning, and an answer weeks later to who moved what and why.

Why is allocation knowledge so hard to hand over?

Ask a duty manager why a particular widebody never goes to a particular stand. The answer comes back in about four seconds, and it is right. That speed is years of apron experience doing its job. The question worth asking is not whether the knowledge is there, it plainly is, but what the operation can do with it when the person holding it is not in the room.

In the airports we work with, the pattern repeats often enough to be worth naming. Part of the policy sits in the system. Part sits in a spreadsheet. A good deal of it sits with the people who have run the apron long enough to know which combinations work and which quietly do not. All of that is expertise the airport has paid for and earned. What it lacks is a copy the system can act on and a colleague can pick up.

That is how expertise accumulates anywhere that runs every day of the year, and plenty of airports operate that way successfully for years. It turns into a constraint only when the operation has to grow or change quickly. Stands come out for resurfacing in the middle of a season. An airline turns up with a fleet type nobody here has placed before. A shift lead moves to another role, and the reasoning behind a hundred good decisions has to be rebuilt from scratch by the people who follow.

What does it mean to write allocation policy as rules?

It means saying out loud what the airport already does, in a form the system can apply. Allegra keeps that in four kinds of rule, and the difference between the first two is the one that matters in a control room.

A constraint is a hard rule. This aircraft type is allowed here, that airline is not, nothing over a certain turn time on that stand. The automatic allocation will not break it. A person still can, but they get a warning, they confirm it, and their name goes on the record.

A preference is a soft rule. Same shape, no block. On a morning that has already gone wrong, an operator can allocate straight past it and the system lets them. This is the part most conversations about automation skip. A preference says what the airport would rather happen without taking the decision away from the person who answers for it.

The other two are quieter. An exclusion takes a stand, flight or airline out of automatic scope while leaving it fully available by hand, which covers the resource operations wants to place itself. An engagement standard sets the time window a gate, belt or counter is expected to be in use, worked out from the flight’s own scheduled and estimated times. Those timestamps follow the milestone set standardised by EUROCONTROL’s Airport Collaborative Decision Making concept, so a window defined this way means the same thing in the next system along.

What about stands that can be split?

Some stands take either one large aircraft or two smaller ones, depending on how the apron is used that day. The industry calls this a MARS stand, short for Multiple Aircraft Ramp System, also written as Multiple Aircraft Receiving Stand. The rule behind it is simple enough to write down: at one of our airports, when the sub-stand is occupied, the two adjacent stands are denied. A spreadsheet can hold that sentence perfectly well. The geometry underneath it, and the clearances that make the configuration viable, sit in IATA’s Airport Development Reference Manual.

What a spreadsheet cannot do is show the person on duty, mid afternoon on a busy Tuesday, that half the stand has already gone, and that the widebody they were about to place now has nowhere to sit. On a timeline, that dependency is visible for exactly as long as it lasts.

Why does Allegra allocate nothing until the rules exist?

Because it starts from no. With no rules active, automatic allocation assigns nothing at all.

That is deliberate. The system does not arrive with an opinion about how your airport ought to work and invite you to correct it. It does what your rules permit, and nothing else.

The order we suggest building in goes from physical facts to commercial ones. Which aircraft fit which stands, first. Then the dependencies between stands that share space. Then the restrictions that come out of contracts, airline by airline. Then the resources operations wants to keep by hand. Preferences last.

If you are replacing an older system, that sequence is also your migration plan. Working through it produces a list of what the old system was able to enforce, and, more usefully, the refinements your team has been making on top of it because the system had no way to express them.

What does rule-based allocation give an operation?

Consistency first. The policy is the same at every hour of every shift, and it does not thin out when the people who know it best are on leave. New joiners inherit a written rulebook instead of a reading list of other people’s habits, which shortens the time before they can hold a shift on their own. Allocation quality still depends on the operational record underneath it, which is the argument for treating the AODB as the single source of flight truth rather than one system among several.

Then a plan that absorbs a bad morning. Close a stand and everything allocable on it moves to a valid resource, gates included, without anyone rebuilding the afternoon by hand. Anything a person has placed stays exactly where they put it, and so does anything arriving from SkyCore AODB. When nothing fits the rules, the turn waits in a standby area for a human rather than being forced somewhere unworkable, so the plan on the screen is always one the apron can actually deliver.

And a record that answers questions weeks later. Every allocation and time change is exported with the person, the moment, the old value, the new value and the reason given, and closures and restrictions the same. When a carrier queries a charge or a slot, the response comes out of a report rather than out of somebody’s memory, which is the discipline that also makes a billing cycle defensible when a charge is disputed.

What does this look like on a live deployment?

Chicago O’Hare went live with SkyCore AODB and Allegra RMS in August 2025, alongside International Gate Control and the Chicago Department of Aviation. The work that mattered there was not installation. It was translating an operation of that size into rules: which aircraft belong on which stands, how carriers are grouped across the terminals, how tows between them are handled, and which of those decisions had to stay in human hands. The system was tailored to their business rules rather than the other way round. What the first months produced is set out in the project announcement.

Put the first rules on paper this week

Back to where this started. The expertise is already in the building, and it is good. The work is giving it a form the system can apply and the next person on shift can pick up.

Take stands. Write down which aircraft fit where, then the dependencies between stands that share space. Your team knows both cold. What is left after that is the judgement the old system had no way to hold, and writing it into rules is what stops it depending on who is in the room, on the days when everything moves at once.

Want to see your own allocation policy as rules? Book a 30-minute Allegra RMS walkthrough, start with the Allegra RMS one-pager, or see where allocation sits in the wider airport management platform.

Frequently asked questions

What is rule-based stand allocation?

It is when an airport’s allocation policy is written as rules a resource management system applies automatically, instead of being applied from memory by whoever is on shift.

What is the difference between a constraint and a preference?

A constraint blocks. Automatic allocation will not break it, and a person who overrides it is warned and recorded. A preference guides without blocking, so the operator keeps the decision.

Can automatic allocation overrule a controller?

No. Anything placed by a person, or received from the AODB, stays where it is.

What happens when nothing fits the rules?

The turn waits in a standby area for a person to resolve. The system does not force an assignment.

How far ahead does it plan?

Continuously out to 48 hours, with a separate longer view running months ahead for planning.

What is a MARS stand?

A stand that can take one large aircraft or two smaller ones, short for Multiple Aircraft Ramp System. It is modelled as a conditional rule, so occupying the sub-stand blocks the adjacent stands for as long as the dependency lasts.