3 min read
638readsWhy a travel planner should never invent a restaurant
Language models are fluent about places that do not exist. Here is the architecture we use to make sure ours cannot be.
Ask a general-purpose AI for three restaurants in Tbilisi and it will give you three, with addresses, in confident prose. Some of them will be real. One might have closed in 2019. One might never have existed at all — assembled from the statistical shape of Georgian restaurant names rather than from any record of a building with a kitchen in it.
This is not a bug that gets fixed with a better prompt. A language model predicts plausible text. A plausible restaurant name is exactly what it is built to produce, and it has no mechanism for telling the difference between recalling one and inventing one. For most uses that is a tolerable flaw. For a travel plan it is not: the cost of a wrong answer is paid by someone standing outside a locked door in a city they do not know, at the end of a day they cannot get back.
The rule we built around it
So we start from a rule that sounds severe and turns out to be liberating:
The model never states a fact.
It is not asked to remember anything. Before a single word of your itinerary is written, code assembles a set of verified entities — places that exist, drawn from records we can point at. The model receives that set and is asked to do the thing it is genuinely good at: sequencing, pacing, and explaining. It decides that the museum belongs before lunch rather than after, and why the walk between them is worth taking. It does not decide that the museum exists.
Everything factual is resolved the same way, by the layer that can be held to account:
- Places come from a verified place cache, built from OpenStreetMap, Geoapify and Foursquare — sources with a record you can check.
- Climate figures come from Open-Meteo's historical records, not from a model's sense of what August feels like.
- Visa status comes from a hand-curated table where every row carries a source link and a verification date.
- Currency conversion comes from published reference rates.
- Budget totals are arithmetic, performed in code. No model is asked to add up a column of numbers.
What happens when a section cannot be verified
The interesting question is not what happens when everything works. It is what happens when something does not — when a data source is down, or a place cannot be confirmed, or the composed output fails validation.
The tempting answer is to let the model fill the gap. It would produce something that reads perfectly well, and almost nobody would notice. We treat that as the worst available option, because a plausible unverified answer is more dangerous than an obvious absence: it spends the trust the verified sections earned.
Instead every section stands alone. It is validated in code, retried once with the validation error attached so the next attempt can correct itself, and if it still cannot pass it renders as a card that says so. One section failing never blocks another, and never blocks the page. You get a plan with a visible hole in it rather than a seamless plan with an invisible lie in it.
The part that is genuinely hard
None of this makes the plan infallible. A restaurant verified last month can close this week. An attraction's opening hours can change without anyone updating the record we read. Our claim is narrower and, we think, more useful than infallibility: every place in your itinerary traces back to a source, every price is labelled an estimate, and where we do not know something we say so rather than generating something that sounds like knowing.
That is a lower promise than most AI travel tools make. It is one we can actually keep.
Put it to the test
Every claim in this post is something you can check on a real plan. One sentence is enough to start one.