Taste Concierge

Inspiration

A hotel concierge often has to turn a guest’s interests into a short, useful plan. Someone who loves a particular film or musician may want a nearby restaurant and a museum that fit the mood of a stay. Search results can provide places, but they rarely explain how cultural taste connects to a practical choice. I built Taste Concierge to explore that connection for Athens, while keeping the origin and limits of each fact visible.

What it does

A guest enters a film, artist, or combination of cultural interests, then sets dining and attraction preferences and a maximum distance. The service resolves the cultural input through Qloo and requests related dining and attraction candidates for Athens. It presents two options in each category when the real responses and available evidence support them. Each result shows whether its cultural match came from Qloo and whether practical venue details came from Qloo or an independent source.

Guests can edit preferences after results appear. The app refreshes the affected category and saves the changed session so it can be restored after reload. It keeps practical constraints separate from cultural affinity. A cultural match does not prove that a venue is open, affordable, accessible, suitable for allergies, bookable, or currently operating. Unknown facts remain unknown.

How it was built

The application uses Next.js and TypeScript, with PostgreSQL on Neon for anonymous session state and Vercel for hosting. Development used Codex assistance for implementation and review. Qloo is central to the product: its live entity resolution and cross-domain recommendations connect a guest’s film or artist interests to dining and attractions. Independently sourced venue metadata provides a second evidence path. These sources form different candidate pools, so our results do not isolate the causal effect of affinity ranking.

The main engineering challenge was preserving useful recommendations without making unsupported venue facts look verified. We added explicit source labels, provenance checks, safe handling for missing coordinates, and preference updates that preserve the session. We also kept upstream usage behind a finite application allowance because Qloo’s provider quotas and previous usage are unknown. The code is MIT licensed.

What we verified

The measured release passes three of seven frozen evaluation targets. Three real film, artist, and combined-input API journeys passed. Five live preference edits refreshed their dependent results and restored their sessions. Five controlled server-fault cases produced the expected safe behavior, without sending actual network requests. Nine of ten frozen profiles returned two categories; the tenth required a venue choice. Nineteen of twenty constraint cases passed; a source-expiry case remains unsupported.

A separate supplemental API session tested P10 after explicitly selecting its canonical venue. Four displayed results passed capture provenance checks and the session restored. This does not replace the original frozen P10 failure, so T1 remains 9/10 and the overall result remains three of seven targets. A separate real browser canary completed one itinerary, a dining preference edit, and a reload. It is not the five-journey browser evaluation.

Limits and next step

The model baseline is disabled. No model outputs, paired comparison, independent human ratings, or quality-improvement claim are available. Free-text interpretation of preferences is also unavailable. Our next step is to obtain admitted free model access and complete the remaining browser and comparative evaluation work. The measured results and methods are published in the evaluation summary.

Built With

• qloo