Check if you'll make it: your route, your checkpoints, your odds.
Say where you land, where you fly out, and how many minutes you have. You get yes / tight / no, the route with every checkpoint, and the rule behind each one. Public data only, every number with a source.
Same documents behind all four. The first system reads the question with a small model and lets code compute the answer. The next two hand the retrieved text to the model and let it reason. The agent gets the first system's tools and decides for itself which to call. Walking and queue times are estimates from public data.
Each question names a trap (a passport control the model might invent, a re-screening exemption it might over-apply, a gate number that looks like another dock's). Same 25 questions, same documents, four designs.
| system | answered / asked / declined right 25 questions | verdict right 19 answerable | route exactly right 19 | rules cited right 19 | all four right |
|---|---|---|---|---|---|
| naive vector RAG | 56% | 21% | 5% | 11% | 28% |
| hybrid search + reranker | 68% | 16% | 5% | 21% | 24% |
| graph + orchestrator | 100% | 100% | 100% | 100% | 100% |
| agent: same tools, model decides | 100% | 84% | 95% | 79% | 76% |
What the 100% means, and doesn't. The expected answers were derived from the same graph and rules the system searches, so this row shows the pipeline is consistent with its own data and that the question-reader extracts the right facts. It does not show the graph matches the building: walking and queue times are estimates, and the 40-minute minimum connection time is commonly cited but unsourced. The text-retrieval rows are a fair comparison because they read the same documents.
The question-reader is the only learned part, and its instructions were tuned on the 25 above. So the 25 were reworded 50 times (typos, lowercase gates, "A10 -> A85", "half an hour", "LHR-ZRH-LIS") after the tuning stopped, and never shown to it before scoring.
| system | answered / asked / declined right (50) | verdict right | route exactly right | rules cited right | all four right |
|---|---|---|---|---|---|
| naive vector RAG | 50% | 16% | 8% | 8% | 24% |
| hybrid search + reranker | 54% | 18% | 8% | 16% | 24% |
| graph + orchestrator | 100% | 100% | 100% | 100% | 100% |
| agent: same tools, model decides | 94% | 89% | 89% | 71% | 72% |
The naive systems mostly don't hallucinate. They hedge: eleven times the baseline asked "which dock is D50 in?" when the question already said D50. Where they answered, they lost the passport control three times and got the route wrong in most of the rest. Better search (row two) answered more often and cited the right rules more often, and still could not compute a route. The agent, with the same tools as the 100% row, gets three questions in four fully right: it never miscomputes a sum, it skips checks and softens verdicts. Why the workflow came first, and what the model got wrong →
Make My Gate answers one question: given where you land, where you fly out, and how many minutes you have, will you make your connection at Zurich Airport, and what will you pass on the way. It gives a verdict, the route, every passport or security checkpoint on it, and the public rule behind each one. A five-day portfolio build, one airport, static public data.
Wayfinding is a solved, sold product: Frankfurt has had indoor routing since 2015 and United's app walks you gate to gate and rebooks you. The rules layer on top of it, will I make it and what will I hit on the way, isn't exposed to passengers anywhere in plain language. This is that layer, on public data, for Zurich, not affiliated with any airline or airport. Read how I built this.
Disclaimer: Make My Gate is a personal portfolio project built on public data. Walking and queue times are estimates. Minimum connection times are set by airlines and airports and change without notice; always verify with your airline or travel agent. Not affiliated with Zurich Airport or any airline. Not responsible for missed connections: check your boarding pass and the signs.