Almost every airline is investing in AI — but you don't want a model guessing your schedule numbers. The right architecture puts a deterministic engine at the core and AI on the outside, via an open standard called MCP.
The aviation-technology market has decided it wants AI in everything — SITA’s research has around 97% of airlines investing in it. That enthusiasm is mostly healthy, but it invites a specific mistake with schedule data: putting a model where a fact belongs. The fix isn’t to avoid AI. It’s to be deliberate about where it sits.
You do not want a language model deciding how many flights operate on a Tuesday, which connections clear their MCT, or whether two legs conflict. Those are facts, derived from the spec, and they need to be exact and reproducible — the same answer every time, traceable to a field and a rule. A model that’s usually right is worse than useless here, because you can’t tell the wrong answers from the right ones.
So the core stays deterministic. No guessing, no sampling — the engine computes your numbers the same way, every run.
That doesn’t mean AI has nothing to offer. It’s genuinely useful around the engine: explain a validation warning in plain English, summarise where the network is under pressure, draft a query from a sentence, narrate a result for a Slack message. None of those require the model to be the source of truth — they sit on top of numbers the engine already computed exactly.
The connective piece is the Model Context Protocol (MCP) — an open standard introduced by Anthropic in November 2024 for connecting AI assistants to external data and tools. Instead of every app inventing its own AI integration, a tool exposes an MCP server, and any MCP-capable assistant — Claude, Cursor, VS Code, and others — can connect to it as a client.
SSIM Toolkit ships a read-only, on-device MCP server. Two words there are doing a lot of work:
The result: you can point your own AI assistant at your schedule and have a real conversation with it, without the model ever becoming the thing that computes — or the thing that leaks — your numbers.
| AI on the outside does | The deterministic core does |
|---|---|
| Explain a warning in plain English | Validate against the spec |
| Summarise where a hub is under pressure | Compute the exact connection windows and slots |
| Draft a query from a sentence | Run the query and return the rows |
| Narrate results for a human | Produce the numbers, reproducibly |
To be unambiguous: the AI does not do the analysis. There’s no hosted service quietly running a model over your data, no proxying of your prompts, no cloud in the path. The engine is deterministic and local; the AI is an optional interface on the outside of it, driven by your assistant through an open, read-only, on-device connection.
AI on the outside, determinism on the inside. The model makes the tool easier to talk to; it never becomes the thing you have to trust for the numbers.
That’s exactly how SSIM Toolkit is built: a deterministic engine at the core, and a read-only, on-device MCP server so your AI assistant can explore the schedule without ever computing or exporting it. The honest version of “AI-powered” — powerful where it helps, and nowhere near the source of truth.
Next: the airline software stack — and where all of this sits in it.
Sources
Two properties do most of the work in trustworthy schedule tooling: the data stays on your machine, and the same file always produces the same answer. Here's why both matter more than they sound.
Sometimes the fastest way to answer a schedule question is to write the query yourself. Here's what it means to treat a parsed SSIM schedule as read-only tables you can ask SQL against — locally, with your data staying on your machine.
A fixed-width schedule file and an analytics warehouse want very different shapes. Getting from one to the other — typed, normalized, partitioned, columnar — is the unglamorous work that makes schedule data queryable at scale.
