A trip plan looks like prose. Its failure modes are arithmetic.

Travel Ruter combines FastAPI, PostGIS, React, Mapbox and model-assisted planning. That list matters because each part has a different job. A language model can interpret an imprecise request. It should not be treated as the timetable.

The constraint layer#

Routes occupy space. Transfers occupy time. A proposal that ignores either can sound plausible while being unusable. We keep geospatial constraints in PostGIS and use the model-facing layer to ask for data rather than invent it.

This does not make the plan automatically correct. Source data can be incomplete. Schedules change. A routing query can be valid and still produce a poor journey. The instrument has to retain those distinctions.

What we keep deterministic#

The model may help translate intent: fewer transfers, a later departure, a different region. Database queries and service code handle the constraints we can represent directly. The interface shows the resulting route.

The boundary is the useful design decision. Models are good at language-shaped ambiguity. They are unreliable stores of operational facts. We use each component for the part it can defend.

Current limit#

The repository remains private and a public demo has not been published. The catalogue can describe the mechanism. It cannot claim that strangers have run it successfully. That proof still has to be made.