-
Crash-test your launch before the market does
-
Launch lab: start with the built-in example or your own idea. The flow is brief, crash test, then next move. Saved studies below.
-
Research starts: AI turns each concept into a testable hypothesis and matches it to real Qloo entities and tags. No evidence yet.
-
Human review: confirm or replace the AI-proposed Qloo signals, flagged if weak, before any evidence is retrieved.
-
Step 2, the concepts: pit three competing positionings against each other, backed by live Qloo cultural evidence, not synthetic data.
-
Step 1, the brief: describe the product, audience, business goal and the decision you need to make. Aggregate audiences only.
-
What held up, what to test next: the AI's read of the Qloo evidence (120 items, 15 of 15 queries) and a validation priority.
-
What held up, what to test next: the AI's read of the Qloo evidence (120 items, 15 of 15 queries) and a validation priority.
Inspiration
Every launch deck has a slide that says "Our audience is young, urban, creative, and loves authentic experiences."
Nobody on that slide has ever met the audience. They were not in the meeting.
We kept noticing the same pattern. A team writes three plausible concepts. An LLM writes a confident, well-formatted case for all three. Every case sounds right, so nothing gets decided, and the real test is whatever the market does after the packaging order has shipped.
Then came the uncomfortable thought:
If an AI can argue for any concept equally well, what is it actually telling us?
Car makers do not find out whether a car is safe by asking it to write an essay. They put a crash-test dummy in it and drive it into a wall. We wanted that for launches: crash the idea into real cultural evidence before it crashes into the market.
So we built Taste Test Dummy. (Yes, it is a pun. The dummy is not the user.)
What it does
Taste Test Dummy is a pre-launch research workflow. Give it a product, an audience, target markets and two or three competing concepts. It retrieves cultural evidence from Qloo, challenges every concept's assumptions, and ends with a decision brief and a list of experiments to run next.
It is built to be inspected, not just read.
| A typical AI launch brief | Taste Test Dummy |
|---|---|
| Starts with a prompt, ends with a persuasive story | Starts with a brief, then retrieves external cultural evidence |
| Buries cultural assumptions in the prose | Shows the selected entities, tags and queries |
| Blurs an observation into a recommendation | Separates evidence, interpretation and hypothesis |
| Finishes with an answer | Finishes with experiments to run |
What you actually experience
- Write the brief. Product, audience, decision, two or three concepts, one or two markets.
- Review the signals. The system proposes Qloo entities and tags. You confirm or replace them. "Similar name" is not "similar culture," and a human catches that faster than a model does.
- Run the crash test. Watch progress as it retrieves evidence, compares concepts, challenges assumptions and builds the report.
- Inspect the results. Overview, Compare, Stress test, Next experiments, Evidence and Report. Search and filter the evidence, and open any record.
- Pick what to test. Download the Markdown report, or come back to the saved study later.
Alongside, it shows an LLM-only baseline generated from the same brief without Qloo evidence, so you can see how grounded and ungrounded output differ.
The rule we are proudest of
Taste affinity is a research signal, not a sales forecast.
We do not produce a "92% launch success" score. Nothing in Qloo's data says that, so we will not say it either. The product shows what supports an idea, what is uncertain, and what to test next.
How we built it
The research pipeline runs in seven stages, from brief to report:
| Stage | What happens | What comes out |
|---|---|---|
| 1. Launch brief | The user describes the product, audience, markets and concepts | A structured brief |
| 2. Plan and resolve | AI drafts the research plan; Qloo resolves entities and tags | Proposed cultural signals |
| 3. Human review | The user confirms or replaces the signals | Approved research inputs |
| 4. Evidence retrieval | Qloo Insights is queried for the confirmed signals | An inspectable evidence ledger |
| 5. Compare and stress test | Concepts are compared; assumptions are challenged against the evidence | Findings and weak spots |
| 6. Grounding audit | A model-assisted check asks whether each finding has supporting evidence | Audited findings |
| 7. Synthesis | Findings become next experiments and a written report | A decision-ready brief |
In parallel: the same brief also goes to an LLM-only baseline with no Qloo evidence, shown next to the grounded result for comparison.
Qloo is the evidence layer, not a logo on a chatbot
| Qloo API | What it does here |
|---|---|
GET /search |
Finds candidate entities for cultural references in the brief |
GET /v2/tags |
Resolves tags used to frame the research |
GET /v2/insights |
Retrieves related places, brands, artists and TV shows from the confirmed signals |
- Real identifiers before retrieval. The model never invents Qloo IDs. It looks them up.
- Cross-domain context. Places, brands, artists and TV shows each show a different side of a concept's cultural associations.
- Location-aware places. Place queries use
filter.location.query. Brand, artist and TV results are not market-specific, and the UI labels them that way. - Explainability on. Insights requests set
feature.explainability=true, so records carry affinity, popularity, tags and the reason for the match when available. - Controlled retrieval. Bounded concurrency, caching and retries on transient errors. The default plan cap is 24 Insights queries.
- Keys stay on the server. The browser receives evidence records, never credentials.
The AI layer: a staged critic, not a one-shot writer
A Python FastAPI backend orchestrates the stages through an OpenAI-compatible chat API (default model deepseek.v3.2). The model frames hypotheses, proposes references, stress-tests assumptions, audits findings, and proposes experiments. Application code, not the model, controls the workflow, retrieval, persistence and the human-confirmation step.
Deterministic concept profiles (evidence counts, recurring tags, coverage, overlap) are computed in code. The model interprets them, and it is instructed not to treat affinity as purchase intent or compare raw scores from unrelated queries as a leaderboard.
Reusable skills bound to stages
Prompt-based SKILL.md methods are bound to the research stages:
| Skill | Role in the pipeline |
|---|---|
brainstorming |
Frame the research plan |
systematic-debugging |
Challenge each concept's assumptions |
verification-before-completion |
Audit whether findings have supporting evidence |
writing-plans |
Turn uncertainty into proposed experiments |
writing-guidelines |
Improve the report prose |
We use skills in a plain sense: instruction sets run through the LLM. They are not autonomous shell agents.
Architecture
The backend is hexagonal. Application services depend on ports (QlooPort, LLMPort, StudyRepository, SkillPort) and adapters are wired at the API boundary. That lets us swap in a clearly labelled fixture adapter without touching research logic.
Stack
Qloo Taste AI API · Python · FastAPI · OpenAI-compatible LLM (DeepSeek V3.2) · React 18 · TypeScript · Vite · httpx · JSON study storage
Challenges we ran into
1. Plausible is not the same as right. Entity matching can return something that looks related and means something else entirely. That is why signal review is a required human step before retrieval, not an optional extra.
2. Global signals that sound local. Only Qloo place queries accept a location filter. Brand, artist and TV results are not market-specific, so a polished paragraph can quietly make a global trend sound like a Mumbai trend. We label geographic scope everywhere and keep shared non-local results separate from per-market evidence.
3. A correlation becoming a recommendation. Models love turning "associated with" into "should launch." We added a stress-test stage, an evidence-grounding audit, and structured reports that separate observation from interpretation from hypothesis.
4. No silent fallbacks. If live Qloo retrieval fails, the app does not quietly switch to demo data. Fixture mode is explicit, labelled as synthetic everywhere, and opt-in.
5. Corporate TLS and the model zoo. Our network's certificate proxy broke Python TLS, and the supplied LLM endpoint did not support chat on every listed model. We fixed the first by using the OS trust store (verification stays on) and the second by testing which models actually work.
6. Long-running research in a simple app. Studies run for minutes. We used in-process background jobs with progress polling, which works for an MVP. We say plainly that it is not a durable queue.
Accomplishments that we're proud of
| What | Result |
|---|---|
| End-to-end live run | Brief to report, including 15 successful Qloo Insights queries returning eight items each in one run |
| Workflow timing (two live runs) | Planning about 33-39 s; research and report stages about 88-133 s |
| Human-in-the-loop signals | Users confirm or replace Qloo entities and tags before evidence is retrieved |
| Evidence you can open | Affinity, popularity, tags and explainability visible per record |
| Honest comparison | LLM-only baseline shown next to the grounded study |
| Skills wired to stages | 24 skills discovered, 5 bound to research stages, with usage traces |
| Customer-grade report | Branded Markdown with evidence tables, citations and caveats |
| Clean frontend | TypeScript check and Vite build pass; keyboard tabs, responsive layout, evidence dialogs |
Also: a product whose answer is often "here is the experiment to run" instead of "launch this one," and live and fixture data are never mixed up on screen. Our demo case, Fizzora (a fictional botanical sparkling drink), is tested across Mumbai and Berlin.
Honesty box. These are observations from development runs, not a formal evaluation. The baseline comparison is a demo aid, not a benchmark. Taste Test Dummy does not predict sales or replace consumer research.
What we learned
- Evidence beats eloquence. Every claim should point at something retrievable.
- Put the human where the model is weakest. Entity matching is where a quick human check saves the run.
- Scope labels are features. "Not market-specific" matters as much as the result.
- Say no to fake precision. Dropping the made-up success score made the product more credible.
What's next for Taste Test Dummy
- Close the experiment loop. Record real test outcomes and compare them with the original hypotheses.
- Stronger grounding. Trace every recommendation back to its evidence records.
- Fair evaluation. Compare grounded and baseline outputs on matched tasks with human reviewers.
- Ready for teams. Authentication, durable jobs, database storage and secure deployment.
Responsible use
A research and decision-support prototype. Qloo affinity is not purchase intent, market size or causality. Briefs are sent to external services, so avoid confidential or personal data. It is built for a trusted environment and has no authentication yet.
Our promise: no more launch decks that sound convincing and have never met the audience.
Thank you to the Qloo team for the Taste AI API and the hackathon.
Built with
Qloo Taste AI API · FastAPI · Python · React · TypeScript · Vite · DeepSeek V3.2 (OpenAI-compatible API)
Built With
- ai
- fastapi
- python
- qloo
- react
- taste
- typescript
Log in or sign up for Devpost to join the conversation.