Decisions in Context

Or how AA and BA should have built their systems

When building AI decisioning systems, especially those linked to applications, we need to think about both the local context and global context for that decision. While we can replicate the local context into a vector store, we might need to alter those vectors for our decision, on top of that we have to pull in the global context for that decision. This means that there is a separation in a well architected AI decisioning system between the application context and the individual decision context.

This is how I ended up sitting in Heathrow for 5 hours, because when AA and BA built their rebooking and failed-to-fly bots they both made fundamental errors, and the key part of that error was the idea that the decision had all the context locally. This is an extremely common flaw in most data systems today, whether its the EDW that pretends it has everything, or these operational decisions that just use what is to hand, the assumption is that the local database contains everything that is required.

How American Airlines and British Airways demonstrated the importance of context in automated…

There is no single store of everything

The first thing to embrace is that it is impossible to have a single store of everything, not just “difficult” or “requiring investment” but “absolutely impossible” this is for two reasons, one that is small and specific, the other which is large and broad.

1. Decisions require their view on the data
2. Reality is big, universe big, and its potential futures are utterly infinite

The first point is simple, to make a decision a person needs the information presented in context, there is no “single view” that helps that. How you view information changes based on the context of the decision, so something that is a driver for one decision is a guide for another.

Trusted AI — Scope, Clarity of Purpose and ensuring positive intent

The second is that you cannot model reality and store it all in a database, not just the items, but all of the relationships and meta-data associated with them. With more and more data actually being external not just to an operational area but the business itself in Collaborative Data Ecosystems it means that trying to create a constant view that includes everything is pointless. This doesn’t matter what technology you are thinking about, you just cannot create a store of everything, whether a knowledge graph, NoSQL store, great big SQL database or just a huge set of files, all you can ever aim for is to have as much of your local context as possible

Insight at the point of action

This is all to say that AI requires the ability to build the context for the decision.

Insight at the Point of Action

And in building that context you need to understand the various dimensions that are required to drive the decision successfully, these are multi-dimensional in nature.

Situational Intelligence — 3D KPIs for an AI Driven World

This means we need to construct the context for that decision, create the situational context that is required to make situational decisions.

Knowledge gives you the context, but then you need to render it for purpose

Which brings us to how you need to work, and how BA and AA should have been working. When we have a decision to make we need to build a context, that means we need three things

1. The stuff we know locally
2. A description of the total available context
3. A way of getting the parts of the context that we need.

Local information is about replication for purpose

The stuff we know locally and we build that by using CDC, replicating both into our operational store and our local vector database, using the sort of pattern that every new application should use

Generative ERP & CRM

The total context

So the next challenge is the total context, this is where knowlege graphs are really going to come in, I don’t need the graph to hold all the content, just where that content is and what it represents. So lets use the BA and AA example to describe what that means.

So AA needs to operationally have all the flights on a PAX, they need operationally the current statuses of all their flights and they need to know all the active PAX that they might need. This enables simple eventing triggers to be done with the application. To help the more complex AI decisions then elements like Weather, Flight Routing and Crew information (hours, locations, etc) is required, this also should have the Active PAX up to date so when a rebooking is required the information is already live.

The additional element here is a knowledge graph that contains not direct information but the way to get information if required, in this case we’ve limited it to BA information.

Building the context

So in our example, at the Operational level (doesn’t matter whether in the operational store itself, or via the vector store), we have a simple rule that is looking at the following simple problem:

Will a delay on one leg result in a passenger missing a subsequent leg?

When the answer comes back “yes” we get a list of the impacted PAX with their flight delay that is impacting them. Now we need to build the full context. Let us say, for simplicities sake, the 4 hour delay on the PHX to DFW leg causes 100 passengers to miss their connection, but only one of them (me) has subsequent legs that are not on American Airlines. For everyone else we just need to take this list of PAX and load them into the vector store ready for processing.

For me however we need some additional information, from BA we need to know the fare rules, rebooking rules, additional flight options and any appropriate customer information that helps (for instance knowing if someone is flying to home rather than from home could alter what you do).

Now in a traditional system it would receive a list of rebooking elements and then just apply them in the local system. However here, because we’ve added in the rebooking rules from BA, which should highlight that the rebooking should be done on the main PAX, which will then recreate a sub-PAX for AA legs, the following can happen.

1. The AA AI creates a list of re-bookings for the 100 people, 99 of these are then directly activated within AA
2. For my flights it would instead create a GenAI envelope which communicates back to BA the rebooking to make

So the AI from AA would still have me going via chilly Philly but instead of just blindly making that change locally it now as the information required to instead make that request back to British Airways.

CDC to the Vector Store, but render for purpose

The point to remember here is that there is a separation between populating the Vector store with the ‘latest’ operational information to ensure an accurate decision, something that should be continual, and the creation of the specific information required for an individual decision. Trying to construct a vector database that has all of the information, and all of the types of vector, required for this decisioning is impractical, therefore taking an approach where you separate out the “whole context” problem from the “operational context” problem means you significantly limit the amount of additional information you need to dynamically load.

As we start building larger and more complex AI systems this need to create purpose specific vectors is only going to increase, and architecting today for that challenge is just a smart idea, and doing so in a way that enables the full context to be included in the decision isn’t just smart, its mandatory.