1.What you give it
The planner takes one document of preferences. Nothing else about you is part of it.
- Countries, and optionally the specific cities inside them
- Dates, or a length in days if you are still flexible
- Who is going: adults, children, and the children's ages
- A budget for the whole party, and a currency
- Pace, and how you are willing to move between places
- What you are there for, and anything you must have
- A free-text note, if there is something the fields cannot say
2.Two of those inputs do more than they look
Naming cities is a narrowing, not a hint. If you list four cities and say that is all you want, the planner will use those four and nothing else, rather than treating them as a starting point and adding what it thinks you have missed.
The note is the only part of the request somebody else wrote, so it is handled differently from the rest. It is cleaned up, then placed in the prompt inside a block marked as the traveller's own words. The instructions around that block say its constraints are binding and that it carries no instructions of its own. A note can tell the planner that somebody in the party cannot manage stairs. It cannot tell the planner to ignore your budget.
3.The steps it actually takes
Planning is a job rather than a request. You ask for it, the server answers immediately with a job, and the screen polls that job until it succeeds or fails. This is why planning survives a closed laptop and a bad connection: the work is not attached to the request that started it.
The phases the screen reports are the steps the runner takes, in order:
- Reading the catalogue, to assemble the pool of places the plan may use
- Searching flights for the corridors the trip might need
- Searching stays for the places it might use
- Asking the model to choose places, order and nights
- Pricing the result and building the three routes
4.Asking twice is free
A job is identified by the question it asks: your preferences, the kind of plan, when the trip last changed, and the model. Submitting the same question twice joins the job already running rather than starting a second one, so a double click costs nothing and a refresh loses nothing.
Reading a job also claims it if nobody has, which is what makes the whole arrangement work in an environment that refuses background work.
5.Which places a plan may use
Before the model is asked anything, a pool of candidate places is assembled from the countries and cities you chose. One function answers that question for the entire system: the flight searches use it, the stay searches use it, the prompt uses it, and the prompt's own tests read the same list. There is no second opinion about what is available.
Anything the model returns that is not in that pool is dropped. That is the mechanism that stops a plan containing a town nobody can book a room in.
6.What the model decides, and what it cannot
The model chooses which places to use, the order to visit them in, and how many nights each one gets. That is the whole of its job. It never produces a figure anybody sees.
Its answer is checked rather than trusted. Place ids outside the pool are dropped. A night split that does not add up to the length of the trip is re-spread by the product's own code. Money comes from one function, and the model is not part of it.
If the model is slow, unreachable or answers with something unusable, a deterministic planner produces the route instead, through the same interface. You get a trip rather than an error page, and the trip is a real one.
7.How the travel between stops is decided
Consecutive stops become a leg. A leg is a flight when it crosses a border, or when it runs beyond about 620 miles. Otherwise it is a drive. Nobody chooses that per trip; it falls out of the geography.
A flight needs airports at both ends, so the catalogue resolves the nearest airport selling scheduled seats to each destination, offline, from a generated list. A destination is a place rather than an airport, and letting each price provider guess its own airport is how two providers come to quote two different trips.
Driving distance is the straight line between two stops with a detour factor applied, and driving time comes from an average speed. That is a pacing estimate and it is good enough to tell a comfortable day from a punishing one. It is not a road route, and Outrouted does not pretend it is.
8.What happens when you change the route
Edits save immediately and nothing is re-planned between them. Re-planning is the expensive call in this product, and a route rebuilt after every change would be slow and would keep moving things you were in the middle of deciding. The budget still recomputes on every read, because that arithmetic is local and free.
When you ask for the route to be made whole again, three rules hold. Your stops are the input: re-planning never adds one, drops one or reorders them, because those are the decisions you have been making. The nights add up to the length of the trip again, spread over the stops that are free to move, and a stay you pinned is not one of those. And every stop has somewhere to sleep, unless a pinned stay already covers it.
Removing a stop marks it rather than deleting it. The next plan is what clears it out, which means an undo is a change of mind rather than a recovery.
9.What it does not consider
This is the honest edge of the tool. None of the following is part of the route:
- Opening hours, closing days, or seasonal closures at a specific place
- Real road routing, traffic, roadworks or mountain passes
- Live seat availability on a particular flight
- Train and ferry timetables, which are not modelled as legs at all
- Visa processing beyond the lead times in the preparation list
- Anything about you other than the preferences you typed