Problem

Picking one restaurant, movie or artist for a group usually means the loudest taste wins. Taste Table scores options for each person and ranks them so the least-happy person is looked after first.

What it does

Each person lists a few favorites. For every person the app resolves those names to Qloo entities (/search), then asks Qloo for recommendations seeded by them (/v2/insights) and gets a per-person affinity score for each candidate. Qloo's top-50 list for one person omits candidates only others surfaced, so the app asks Qloo again (filter.entities) for that person's real affinity for every candidate instead of assuming zero. Picks are ranked with a maximin rule: an option is only as good as the least-happy person's affinity. Each pick says who matches it least and by how much, so the compromise is visible.

Qloo workflow

/search resolves free-text favorites to entity IDs (one call per favorite).
/v2/insights with signal.interests.entities (and filter.entities to re-score a given candidate for each person) returns per-person affinities for movies, places, artists, TV shows or destinations.
Only favorite names are sent to Qloo, never personal data. The API key stays on the server (environment variable) and is never in the browser or the repo. Responses are cached in memory only, never stored in the repo.

Limits

Affinities come from the favorites you enter. Places need a city. Results are aggregate cultural affinities, not facts about what any individual will enjoy.