Beyond the prompt: how WanderBu checks whether an AI travel plan actually works

A travel itinerary can sound excellent and still schedule lunch before the traveller’s flight lands. It can recommend a real hotel in the wrong city, leave a night without accommodation, or describe an uncertain connection with unjustified confidence. Each individual sentence may look reasonable while the journey as a whole fails.

Consider an illustrative arrival day: a family is still connecting through Kuala Lumpur at noon and will not reach Ho Chi Minh City until 13:30, yet its generated plan recommends lunch in District 1 at 12:00. Asking a model to “be realistic” expresses the intention. The application still needs a way to identify the conflict and act on it.

At Imajin, this is the engineering problem behind WanderBu. Gemini helps reason about travel intent and synthesise recommendations. Around that reasoning, we build explicit representations of the trip, evidence about places, deterministic checks, and review decisions. The following mechanisms are implemented in the codebase; they describe how we approach reliability, rather than a claim that every generated journey is correct.

A travel plan contains relationships that prose alone makes difficult to inspect: a meal belongs to a day, a day starts from a location, a flight has arrival and connection times, and an overnight stay covers particular dates. Representing these elements as structured data gives the application something concrete to validate.

WanderBu’s deterministic audit operates without asking another language model for an opinion. It checks route continuity, anchors accommodation and airport movements, and includes corrections for meals scheduled before a traveller reaches a stay or while a journey is still underway. For relaxed groups, multiple major transport legs can produce a pacing warning.

The response depends on the finding. Some inconsistencies can be corrected; others need a warning or reduced confidence. A disconnected route should not become “verified” through a silent rewrite of geography. Encoding these distinctions is domain engineering: deciding which rules are dependable enough to enforce and which situations require judgement.

A plausible venue name is not a stable identity. Hotels can share names across cities, restaurant chains have multiple branches, and a search result can be a strong text match while being geographically wrong. Attaching a map pin to the first result can turn an ambiguous recommendation into a precise-looking mistake.

WanderBu’s place-resolution evidence records identity similarity, country agreement, distance, and competing candidates when they are fetched. Its resolution policy can reject candidates for weak identity, country mismatch, distance, or insufficient context. It also records why a lookup did not resolve successfully.

For our example family, this matters after the meal conflict is fixed: the replacement venue must belong to the intended city and branch. External data helps ground a recommendation, but the application must still decide whether that evidence supports this particular match. A failed resolution is useful information to preserve.

An itinerary might have appealing activities, good geographic grouping, and sensible pacing while still leaving one night without accommodation. Combining everything into an average can hide the problem. WanderBu therefore separates overall quality from critical blockers.

The implemented gate asks for human review when the weighted score falls below its threshold or any critical blocker remains. Blockers include unresolved validation errors, unsupported itinerary evidence, uncovered accommodation nights, and certain risky flight connections. These conditions do not disappear because other dimensions score well.

A plan marked for review remains readable. The status directs the traveller or reviewer to inspect the quality report before relying on it; it does not imply that a human has already approved it. The report preserves the decision, blockers, score, and engine version. These scores express an application policy, not a statistical probability that the trip will succeed.

Retrieving information is only one part of grounding an AI application. A venue may close, a source may change, and yesterday’s operating hours may be unsuitable for today’s schedule. The system needs rules for when previously useful evidence stops being eligible.

WanderBu’s place-knowledge implementation provides a staff review process for sources such as official operators, government sites, and tourism boards. Reuse depends on approval, complete identity information, geographic consistency, freshness, and the fields needed by the requesting feature. Schedule consumers have stricter requirements for the recency of human review of current hours.

A changed source fingerprint returns an entry to draft and saves proposed facts for review. Refresh failures make the entry ineligible; missing, stale, ambiguous, or incomplete knowledge falls back to the provider path. This mechanism does not make a source infallible. It makes the conditions for trusting and reusing it explicit.

Generation is not the last operation that can change a trip. Reservation synchronisation, route adjustments, and other application logic can modify the itinerary after earlier checks have run. A validation result for a previous version cannot establish that the final version still meets the same conditions.

WanderBu calculates its publication quality report after those mutations. This places the acceptance decision at the boundary where the completed plan is persisted. Returning to our arrival-day example, correcting lunch is insufficient if a later change creates a new conflict in the schedule.

A separate deterministic evaluation rubric supports examining feasibility, geographic coherence, evidence coverage, traveller fit, and unsupported transport claims. Repeatable scoring makes changes easier to investigate. It is still a proxy for quality: it does not replace human evaluation or demonstrate superiority over another system without a controlled comparison.

A prompt can ask a model to respect bookings, remember transfers, and avoid uncertain recommendations. WanderBu represents these concerns in data structures, checking rules, evidence policies, and review states. Reproducing that behaviour requires implementing and maintaining those mechanisms across changing inputs and sources.

A capable model connected to equivalent infrastructure could support similar behaviour. The defensible advantage is the accumulated engineering: domain rules informed by failure cases, maintained knowledge, regression coverage, and an application workflow that responds to uncertainty. These assets can become more valuable as the product develops; they are not created by changing a prompt alone.

This is how Imajin approaches AI application development. We define what an acceptable result requires, give models useful context, connect their suggestions to evidence, and enforce the constraints the product depends on. Travel makes those dependencies unusually visible. The same discipline matters wherever generated recommendations must become decisions people can act on.