How it works

CoastWise is a retrieval-augmented planner. The knowledge comes from a curated Coastal Karnataka dataset; the language model only writes the wording around it.

Architecture

  ┌──────────────┐    ┌────────────────┐    ┌──────────────────┐
  │  User input   │ →  │ Query process   │ →  │  RAG retrieval    │
  └──────────────┘    └────────────────┘    └────────┬─────────┘
                                                      │
                          ┌───────────────────────────▼──────────────┐
                          │  Coastal Karnataka knowledge base         │
                          │  places · stays · food · activities ·     │
                          │  transport · curated notes (+ sources)    │
                          └───────────────┬──────────────────────────┘
                                          │  pgvector cosine search
                          ┌───────────────▼──────────────┐
                          │  Rule-based ranking           │
                          │  interests · diet · style ·   │
                          │  intensity · feedback signal  │
                          └───────────────┬──────────────┘
                                          │
                     ┌────────────────────▼─────────────────────┐
                     │  Route optimisation + budget optimisation │
                     └────────────────────┬─────────────────────┘
                                          │
                              ┌───────────▼───────────┐
                              │  LLM narrative layer   │
                              └───────────┬───────────┘
                                          │
                        ┌─────────────────▼──────────────────┐
                        │  Personalised itinerary → feedback  │
                        │  feedback → ranking signal (loop)   │
                        └────────────────────────────────────┘

1 · User input

Origin, destinations, days, people, budget, dates, style, interests, diet, transport, hotel preference and activity intensity are captured as one typed request object.

2 · Query processing

The request is turned into a retrieval query and a set of hard filters (diet, style, intensity, towns) plus soft scoring weights.

3 · RAG retrieval

Curated notes are embedded and searched in Postgres with pgvector using cosine similarity; when embeddings are unavailable a keyword fallback keeps the demo working.

4 · Knowledge base

Places, beaches, temples, stays, restaurants, cuisine, activities and transport legs — each row keeps a source reference and an Approximate / Live / Unavailable confidence label.

5 · Rule-based ranking

Deterministic scoring on interest overlap, diet match, price fit to travel style, activity intensity, hidden-gem bonus and an aggregated feedback signal.

6 · Route & budget optimisation

A nearest-neighbour pass over coastal coordinates orders towns to avoid backtracking; the budget optimiser fits transport, stays, food, activities, entry fees and misc to the total and proposes cheaper swaps when it overruns.

7 · LLM narrative

The model writes only the titles, taglines, day headlines and notes over the already-selected records. It is instructed to use retrieved knowledge and never invent prices, ratings or schedules.

8 · Feedback loop

Ratings and per-category feedback are stored and used as a controlled ranking signal for future recommendations — never as automatic model retraining.

What we never fake

Hotel prices, ratings, transport schedules, opening hours and ticket availability are never invented. Anything not verified live is labelled Approximate, and unavailable data is labelled Unavailable.

The architecture is modular so real Maps, Weather, Bus, Flight, Hotel and Restaurant APIs can replace the approximate layers later.