If I Had These Capabilities Then: Travel Disruption Is Where Prediction Meets Human Judgment

Decision Architecture Pathway

Connecting operational forecast models to unstated passenger intent:

1. Predictive Signal Calculates delay & misconnect odds

2. Operating Constraints Inventory, seat tiers & ticket rules

3. Customer Values Time, children, seats & trip intent

4. Recommendation Exposes tradeoffs & candidate paths

5. Human/Customer Choice Empowered final commitment

A flight is cancelled. The schedule changes. A connection becomes impossible.

• Seat Inventory
• Schedule Routing
• Fare Rules
• Missing a Wedding

From a systems perspective, the problem may be represented as inventory, availability, routing and rules. From the traveller's perspective, they may be missing a wedding.

That gap between the system's representation of a problem and the person's experience of it has always interested me.

It is also why I think travel is a useful environment for thinking about predictive capability. Not because prediction eliminates disruption. Because it can potentially give people more time to respond.

Prediction Is Valuable When It Changes the Next Decision

Suppose we can estimate that a particular connection is increasingly unlikely to succeed. That prediction by itself isn't a product. It becomes valuable when we decide what to do with it.

Should we wait because acting too early could create more disruption than the event we are predicting?

Those are product questions, not model questions. They are also tradeoffs:

• If we communicate too early, we may create unnecessary anxiety.
• If we communicate too late, we remove options.
• If we automatically change an itinerary, we may solve the operational problem while destroying the reason the customer chose that journey in the first place.

That is where I would want predictive capability connected to decision support, rather than treated as an automatic instruction.

The Customer's Goal Is Not Always Visible in the Reservation

This is the problem I would be most interested in exploring. A booking contains information. It does not necessarily contain intent.

Two passengers travelling on identical itineraries may value completely different outcomes:

• One wants to arrive as early as possible.
• Another wants to avoid an overnight stop.
• Another is travelling with young children.
• Another cares about keeping a particular seat or travelling with someone else.

A predictive system may tell us what is likely to happen operationally. It cannot automatically tell us which compromise the customer would prefer.

This is where generative interaction could potentially help. Not as an open-ended chatbot replacing every service channel. More narrowly.

If disruption becomes likely, could the system explain the situation in plain language and surface the small number of realistic options? Could the traveller express what matters most? Could that information become context for a recommendation?

Now we have a richer decision. The prediction tells us what may happen. The deterministic systems tell us what inventory and rules allow. The customer tells us what they value. The recommendation brings those together.

That feels much closer to the actual problem.

I Would Still Be Cautious About the Word "Best"

Recommendation systems love the idea of the best option. I'm less convinced.

That is where the Meta-Problem Method resonates with me. The method emphasizes understanding the goals before evaluating the options, because different goals naturally produce different tradeoffs.

In travel disruption, that isn't theoretical. It is the product.

The Prototype I Would Run

I would begin with employee decision support rather than immediate customer automation.

Take a known disruption scenario. Provide the system with the operational context and available alternatives. Allow it to produce a short synthesis and perhaps two or three suggested options. Then compare the experience with the existing process:

• Does the employee understand the situation faster?
• Are the options valid?
• Does the recommendation overlook customer context that an experienced employee immediately notices?
• What additional information would improve it?

That last answer is probably the most valuable. Because it tells us what the system needs before we increase its role.

The experiment isn't only testing the model. It is teaching us about the workflow. And once we know that, we can decide whether the next investment belongs in prediction, retrieval, customer preference capture, deterministic automation—or somewhere else entirely.

That is what I mean when I talk about using uncertainty productively. We don't need perfect foresight. We need enough information to make the next decision better than the one we would otherwise have made.