Introducing AI into an Integrated Operations Control Centre (IOCC) requires a clear view of how business processes, organisation and people will evolve. ACC focuses on the supporting technology and can introduce airlines to specialists who can help review and redefine these dimensions.

This article focuses on systems: how decision support should reflect the airline's agreed operating model, from recommendation through authorisation to execution.

Consider a system that recommends holding a departure to protect connecting passengers. It compares the expected connection benefit with the additional delay and the consequences for the aircraft's next rotation.

For a controller to use that recommendation, the solution must also answer practical questions. Is the evidence current? Does the proposed action fall within this controller's authority? Is another authorisation required? And how will the authorised choice reach the teams and systems responsible for carrying it out?

These questions translate operational authority into requirements for decision support.

Airline operations controller reviewing decision support alternatives in an integrated operations control centre.

Represent authority alongside the recommendation

A user's access to a screen is only one part of the picture. Authority can depend on the decision being taken, its operational scope and the conditions under which an action is permitted.

A decision support solution should make those boundaries explicit. For each supported decision, it should identify the role permitted to authorise the action, the applicable limits, any required agreements and the route for escalation. These rules must come from the airline's approved operating model and remain under business ownership.

For example, a controller might be authorised to approve a limited hold under specified conditions. If the expected consequences exceed that mandate, the system should recognise the boundary and direct the case to the designated authority. The actual roles and limits would need to be established with the airline.

This distinction builds on existing work. Bain's RAPID framework separates recommendation, input, agreement, decision and performance roles. Research by Parasuraman, Sheridan and Wickens distinguishes automation of information acquisition, analysis, decision selection and action implementation.

Translating these distinctions into airline system requirements is part of the work we are developing in Project Altitude.

Present a decision the controller can assess

A recommendation needs enough context for the authorised person to exercise judgement.

For Altitude's first controlled application, we propose one principal recommendation with one or two viable alternatives. In the hold/release case, that could mean comparing departure at the current planned time with different feasible hold durations.

The presentation should bring together:

An option should be presented as feasible only when the necessary checks support that conclusion. If material information is missing, the system should make the gap visible and follow the airline's defined handling procedure.

This allows the controller to inspect the trade-off and understand why an alternative ranks differently.

Reassess when the operational picture changes

A recommendation belongs to a particular state of the operation. New passenger readiness information, a revised arrival estimate or a change affecting the next rotation may alter its value or feasibility.

Each recommendation should therefore be linked to the information and assumptions used to produce it. When a material change occurs, the solution should identify the affected recommendation, update the comparison and indicate whether a pending or previously authorised action needs renewed review.

The airline must define which changes require reassessment or renewed authorisation. The system should apply those rules consistently and make the change visible to the responsible user.

For the hold example, the controller should be able to see what changed, how it affects the alternatives and whether the original authority conditions still apply.

Make escalation actionable

An escalation should carry the decision context to the person who can act on it.

The solution should show the reason for escalation, the designated recipient, the response deadline and the current status. The receiving role should have access to the same evidence, alternatives and constraints that prompted the escalation.

The airline also needs to define what happens if the response does not arrive in time. The system should support that agreed procedure and make the unresolved status visible. Silence should not be interpreted as authorisation unless an explicit, applicable delegation rule permits that behaviour.

The specific escalation triggers and timeout handling remain matters for validation in Altitude's controlled application.

Track authorisation through to execution

An authorised decision still needs to reach execution.

The solution should distinguish between an action being recommended, authorised, submitted for execution and confirmed as executed. A rejected request, failed interface or unacknowledged instruction should remain visible to the responsible team.

In the hold case, authorising a revised departure plan does not establish that every affected operational party has received or implemented it. Integration with existing operational systems must provide an appropriate acknowledgement or confirmation mechanism.

A traceable record should connect the evidence available at the time, the recommendation, the authorised choice, any subsequent changes and the action actually executed. This supports operational review. Assessing whether another choice would have produced a better outcome requires additional analysis.

What Project Altitude will test

These are proposed system design principles, informed by Altitude's work on decision capability and authority. Their operational value remains to be tested.

The next step is to examine them through a controlled connection protection case: whether a controller can assess the alternatives, whether authority boundaries and escalation work as intended, whether changed evidence is handled clearly, and whether the authorised action can be traced through execution.

For an airline evaluating a decision support solution, this provides a practical test: follow one recommendation from the evidence that produced it to the authority that approved it and the confirmation that it was carried out.

References