What we learned building WanderBu’s travel knowledge base

A traveller might ask whether a bank card works on the MRT and whether they can still catch the last train. Those sound like simple transit questions, but they depend on different evidence: card rules come from one source, while service times depend on route and date. A model can phrase an answer; it cannot keep those sources current or the claims straight by itself.

Travel facts also age at different rates. Entry rules can change quickly; a neighbourhood description may stay useful for years; opening hours can shift with the season. Putting all of that text in one index does not make it reliable.

As we built WanderBu, we found that maintaining the knowledge behind the planner takes as much care as retrieving it. The work starts with choosing what is missing, then follows each proposed fact through review and release.

More travel content is not automatically more useful. A destination can have plenty of attraction descriptions and still lack practical guidance on transport, accessibility, or local etiquette. WanderBu tracks coverage by destination and topic, from logistics and neighbourhoods to seasons, day trips, and food.

Coverage gaps are one signal; repeated product demand is another. A destination enters the discovery queue only after at least ten successful place lookups across two trip-generation runs and two place IDs within 30 days. That filters out one-off searches. Editorial priorities and outside rankings are recorded separately, so a curated choice is not mistaken for observed traveller demand.

Before research starts, the queue checks whether the topic already meets its approved coverage target. If it does, the job is skipped. That leaves more room to work on places where new guidance could help.

Once a topic is selected, WanderBu fetches up to four public HTTPS pages, with size limits and host checks. Gemini drafts specific claims from those pages alone. The fetched text is treated as untrusted input, and unsupported details are left out instead of filled in from the model’s memory.

Each claim points to an exact excerpt. Automated checks confirm the excerpt appears on the page and that the proposal has more than one piece of evidence. For topics such as safety, entry, transport, or seasonal hours, sources must also come from independent publisher domains. Search results are not used to fill the knowledge catalog.

These checks make a draft easier to trace, but they cannot tell whether a quote really supports the claim. A reviewer sees the excerpts, publication dates, fetch time, and a fingerprint of the page content, then decides whether the wording is accurate and still useful.

A research worker can waste time revisiting covered topics, create duplicate drafts, or finish after an editor has already changed the source material. WanderBu keeps a job record for each destination and topic. Cooldowns, a lease that prevents two workers taking the same job, limits on pending drafts, and retry delays help control when work runs again.

The system also fingerprints source URLs and page content, then compares new claims with approved knowledge and earlier drafts. That will not catch every near-duplicate, but it reduces repeat work and gives reviewers a useful history.

When a fact expires or its source changes, a replacement draft points to the version it is meant to update. If an editor has changed that version in the meantime, a revision check stops the older draft from overwriting their work.

A generated proposal does not go straight into the planner. Pending drafts are kept apart from the approved knowledge search can use. If a reviewer rejects one, WanderBu keeps the decision and source fingerprints for the record, but creates no search vectors for it.

Reviewers can edit a claim, set a date to check its evidence again, and record why they approved it. Before publishing, WanderBu creates search vectors—the numeric representations used to find related claims—for both the current and fallback search configurations. It validates them, then saves the reviewed claim, vectors, draft status, and audit record in one transaction. If vector generation fails, the draft stays unpublished.

Facts expire on different schedules. Museum hours may need checking every few months; a neighbourhood description can last much longer. Reviewers renew the claims they have checked and let the rest expire. If a claim has not changed, its existing vectors can be reused. If it has, only the changed chunk needs new ones.

Editors and research workers make changes in staging. A deployment job promotes approved changes from a fixed revision. It validates the catalog schema and search-vector settings, then records the promoted revision with the catalog. If anything fails, production keeps the previous version.

Before promotion, we run the same retrieval queries against the candidate catalog and the production baseline. The checked-in evaluation set has 67 fixed query-and-topic pairs across 15 groups, including entry, accessibility, dietary needs, route planning, and local aliases. A release is blocked if NDCG@10, which measures ranking quality in the top ten, drops by more than 0.03, or Hit@3, which checks whether a relevant result appears in the top three, drops by more than 0.04. These thresholds can catch search regressions; they do not tell us whether every itinerary is good. That needs separate trip comparisons.

Production activity also helps choose future research topics. Staging receives aggregate country and city demand linked to overnight coverage. It does not receive user IDs, trip contents, run IDs, place names, or raw location hints. The research queue gets a demand signal without bringing along a traveller’s trip history.

A model can summarize a web page. The product still has to decide why that page was chosen, which claims it supports, whether someone checked them, and when they need another look. It also needs a way to spot duplicate research and stop a catalog update if search gets worse.

In WanderBu, those decisions live in the research queue, source records, review tools, and release checks. As we add destinations and run into edge cases, the evidence and rules stay with the product. That is what keeps the knowledge useful over time.

Travellers do not see the queue or release checks. They benefit when we can trace where a recommendation came from and update it when the facts change. We bring the same engineering experience to other AI products.