AI on the outside, determinism on the inside

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.

The wrong place for a model

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.

The right place for a model

That doesn’t mean AI has nothing to offer. It’s genuinely useful around the engine: explain a validation warning in plain English, summarise what changed between two schedules, draft a query from a sentence, narrate a diff 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.

MCP: the open standard that makes it clean

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:

• Read-only. The assistant can explore your schedule — query it, ask about it, summarise it — but it cannot modify anything. It reads facts; it doesn’t change them.
• On-device. The server runs locally, alongside your data. Your schedule isn’t shipped to a third party for the AI to look at it; the assistant reaches a local socket, and the data stays where it already was.

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 a diff between two files	Compute the exact added/removed/changed
Draft a query from a sentence	Run the query and return the rows
Narrate results for a human	Produce the numbers, reproducibly

What this is not

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.

Doing it well

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

• Anthropic — Introducing the Model Context Protocol
• Model Context Protocol — documentation
• SITA — Air transport IT insights (AI investment)