UNSTUCK

Inspiration

Choosing something together sounds simple until two people have very different tastes. Most recommendation systems either optimize for one person or collapse multiple preferences into an average profile.

CommonGround takes a different approach: it looks for the strongest cultural bridge where the less enthusiastic person is still well served.

What it does

CommonGround is an adaptive taste decision agent for two people.

Each person provides a few taste signals and chooses a target domain such as movies, music, or restaurants.

The agent:

1. builds two independent taste profiles,
2. retrieves candidate recommendations for each profile,
3. compares their overlap,
4. checks whether the common ground is actually strong enough,
5. widens the retrieval window once if the first result set is weak,
6. ranks the final shared candidates using a fairness-first score.

Instead of relying mainly on the average affinity, CommonGround gives the strongest weight to the weaker-person affinity.

This means a 95% / 35% recommendation should not beat an 80% / 78% recommendation simply because its average score looks acceptable.

How I built it

The application uses a lightweight Python backend with a browser-based HTML/CSS/JavaScript interface.

The recommendation layer is designed around the Qloo API:

• /search resolves taste names into Qloo entity IDs
• /v2/insights retrieves affinity-based recommendations for each profile
• feature.explainability=true is used so the live version can expose which interests influenced the recommendations

CommonGround then performs its own group-ranking logic on top of those results.

The ranking currently uses:

• 72% weaker-person affinity
• 20% mean affinity
• 8% balance between the two people

If the initial overlap is missing or too weak, the agent automatically expands the candidate search once before making its decision.

Challenges

The main challenge was defining what a "good compromise" actually means.

A simple average can hide a bad recommendation. One person can love something while the other strongly dislikes it, yet the average can still appear reasonable.

The solution was to make the weaker person's affinity the dominant part of the score and to expose both individual affinities in the interface.

Another challenge was keeping the Qloo integration honest during development. The local version currently uses clearly labelled deterministic demo affinities while the live Qloo API adapter is being completed with the hackathon API key. The application does not pretend that demo data comes from Qloo.

What I learned

I learned that multi-user recommendation is not just a recommendation problem — it is also a decision and fairness problem.

Qloo can provide rich cross-domain cultural affinity, while the application can add another layer of reasoning about how multiple people's preferences should be reconciled.

What's next

The remaining steps are:

• connect the verified live Qloo API responses,
• surface Qloo explainability data in the result cards,
• deploy the live demo,
• test the system with more combinations of tastes and domains.

Built With

• css
• html
• javascript
• python
• qloo-api
• rest-api