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 three. The first system reads the question with a small model and lets code compute the answer. The other two hand the retrieved text to the model and let it reason. 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, three retrieval 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% |
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% |
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. What the 100% does and does not prove →
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.