I wanted the practical details to travel with the plan.
Travel planning spreads one decision across maps, transport sites, entry rules, recommendations, and personal notes. I built Atlas to bring those questions into the same conversation as the itinerary: entry requirements, rail connections, local facts, community context, hot spots, and practical caveats.
A destination alone does not identify the relevant entry requirements. Passport and trip context matter. Atlas supports clarification before continuing visa and document questions.
Decision: clarify before personalizing.
02 / Ground
Keep the answer connected to the trip.
Trip Q&A uses saved trip, city, and activity context plus knowledge lookup, then a small summarization step. A question about the trip does not need to regenerate the itinerary.
Decision: separate answering from editing.
03 / Plan
Change the requested part.
Typed patches use the same reducer actions as the interface. Obvious moves and removals are deterministic; fuzzy edits use a scoped model call. New named venues must come from the user, the current trip, or verified candidates.
Decision: constrain what a model can change.
04 / Reuse
Share knowledge, preserve personal choices.
Reusable city slices are keyed by destination, trip shape, and venue data. Dates, pace, budget, and pins are adapted locally. Personalized results never flow back into the shared cache.
Decision: cache the reusable work, not the traveler.
Select a stage to explore the engineering.
The hard part
A small edit can break a whole trip.
Changing one activity can introduce a venue from the wrong city, overwrite another day, or make a connection infeasible. I scoped regeneration to the requested days, checked venue provenance, and marked affected parts for explicit refresh when feasibility changes.
Freshness has a cost. Atlas keeps last-known metadata while refreshing it, and gates shared itinerary caches on geography, venue eligibility, density, and duplication. A fallback can serve a request without becoming reusable truth.