How I built an itinerary validator for AI travel plans

AI travel planning is useful until the itinerary becomes a real Tuesday at 3 p.m.

That is where the failures appear. A model can write a clean five-day Paris plan. It still does not know that the museum day lands on the weekly closure, that the restaurant moved, or that a timed-entry attraction sold out before the trip.

I built ValidaTrip as the validator step after the AI draft. It does not write the trip from scratch. It takes the plan you already have and checks whether it works on the ground.

The failure mode

A travel itinerary has two different jobs.

First, it has to be a good list. The places should match the traveler's interests. The neighborhoods should make sense. The plan should not send someone across a city twice in one afternoon.

Second, it has to survive live constraints. Each place has hours, booking windows, public holidays, seasonal schedules, temporary closures, and location ambiguity.

LLMs are good at the first job. They are weak at the second job.

That split shaped the system. The validator accepts a pasted AI itinerary, resolves each place, then checks the live constraints against the user's dates.

The primary product page for this flow is Check a ChatGPT itinerary. The same validation pattern also covers Gemini itineraries, Claude itineraries, and Perplexity itineraries.

Parser first, model second

The input is intentionally messy. Real travel notes look like this:

• Friend texts with half-remembered restaurant names
• Blog snippets copied with booking notes
• Google Maps short links
• ChatGPT day plans
• Reddit comments
• Duplicate names with different wording

The system starts with deterministic extraction. Bullets, day headings, map URLs, and common booking phrases are cheap to parse without a model.

The model step handles the ambiguous cases: vague names, mixed prose, and category cleanup. That keeps the expensive part narrow. It also gives the product a better failure mode. When the parser is certain, it stays deterministic.

I published a CC BY 4.0 public corpus for this exact shape: validatrip-public-data. It includes 54 pasted-itinerary sample cases, source markdown, a schema file, comparison data, and prompts that generate itineraries worth validating.

The JSONL file is here: ai-itinerary-validation-samples.jsonl.

The same corpus is also published as a Hugging Face dataset card: validatrip-ai-itinerary-validation-samples.

The corpus is not user data. It is not a statistical study. It is a test and demonstration set for validation behavior.

The checks

After extraction, each named place goes through a set of checks.

1. Resolve the place to a real venue.
2. Attach coordinates and neighborhood context.
3. Check opening hours against the trip dates.
4. Flag weekly closed days and seasonal closures.
5. Flag booking-sensitive categories.
6. Detect duplicates.
7. Separate day trips from in-city clusters.
8. Show everything on a map.

That means the answer to “is this a good itinerary?” becomes more specific.

The useful questions are:

• Which stops are closed during the trip?
• Which stops need a reservation now?
• Which names failed to resolve?
• Which places are duplicates?
• Which stops belong together by neighborhood?

The dedicated hours page is Validate trip hours against your travel dates. The organization page is Organize travel recommendations.

Why source-cited AI still needs validation

Perplexity is a good example. It can cite a travel blog. That proves the blog exists. It does not prove the restaurant from the post is open this month.

A cited itinerary still needs current place resolution. It still needs date-aware hours. It still needs booking flags.

So the right sequence is simple:

1. Use an AI tool for the first pass.
2. Paste the result into a validator.
3. Replace the stops that fail live checks.
4. Build the final day plan from the checked list.

That is the product boundary I wanted ValidaTrip to own. It is the layer after the AI answer, before the traveler trusts it.

The public reference layer

I also keep an AI-readable reference file for the product: llms-full.txt.

It lists the main validation pages, the direct answers those pages support, the schema coverage, and the public entity signals.

The public data repo mirrors that file. That gives crawlers and researchers the same entity context outside the product domain.

The project is intentionally narrow. It does not compete with the itinerary generator. It checks the generator's output.

That narrowness is the point. Travel AI tools already produce the first draft. The missing step is the boring one: open hours, closures, booking windows, duplicates, neighborhoods, and a map that reflects the real trip dates.