NameRadar

A naming agent grounded in Qloo's taste graph: it finds the shows, bands, games and brands your customers already love that share your name, then finds you a clean one.

Comment

Inspiration

Every founder names something. Most check a trademark database and a domain registrar, and then discover their customers already know the word as something else. Mondo had to become Monzo. Sambuck's lost to Starbucks. Small businesses have paid tens of thousands of dollars for forced rebrands. Trademark search answers "who registered this word?" The question founders actually need answered is cultural:

Do the people I'm selling to already associate this name with something they love, and how strongly?

That's a taste question, and it depends on who your customers are. "Euphoria" is the hit HBO show to a young audience and just a word to many others. An LLM can recall famous collisions, but it can't tell you how much your customers care. Qloo can.

What it does

NameRadar is a naming agent grounded in Qloo's taste graph.

  1. You describe your audience by what they already love: 1–4 brands, artists or shows (with autocomplete from Qloo search), plus an optional age range and launch region.
  2. It finds every cultural namesake of each candidate name across Qloo's 250M+ entities: brands, music, film, TV, podcasts, games, books, places and people.
  3. It measures how much this audience cares about each one. Qloo Insights scores the namesakes against your audience's signals. NameRadar then places each score on that audience's own Qloo ranking for the domain: "≈ #7 of this audience's TV shows".
  4. It gives a verdict per name (RED taken for this audience, AMBER crowded, GREEN clear for this audience) on a radar you can explore. Click any namesake to see the full formula, what the namesake means to its fans (Qloo taste tags), and whether its fans look like yours (Qloo demographics).
  5. It fixes the problem. When names are taken, NameRadar proposes alternatives and screens every one against Qloo before recommending it, then produces a memo with questions for a trademark attorney. The planner is pluggable. With an LLM key configured, a Claude tool-use agent invents the alternatives, decides which collisions to inspect and writes a memo citing Qloo entity ids. The public demo currently runs the deterministic planner (labelled planner: deterministic in the UI), so every judge gets the same reproducible, Qloo-only behaviour.
  6. Flip the audience. Re-score the same names for a different audience and watch verdicts change. (An in-app "LLM-only" comparison is built in and activates when an LLM key is configured.)
  7. Evidence trail. Every Qloo request is listed (endpoint, parameters, status, latency, cache hit). The key never leaves the server.

How Qloo makes the difference (measured, live)

On 20 pre-registered names × 3 contrasting audiences (365 live Qloo calls, 0 errors):

  • An audience-blind name search (the registry-style baseline) flags 16 of the 16 common words as taken, for everyone. That's true but not actionable.
  • NameRadar's Qloo-grounded scan changes its verdict between audiences in 35% of name × audience pairs. Examples from the live run:
    • Euphoria is red for young hip-hop fans (HBO's Euphoria ≈ #7 of their TV) and green for cozy gamers.
    • Nova is red only for older coastal shoppers (PBS NOVA).
    • Halo is red only for cozy gamers.
    • Coined names stay clear for every audience.

These are proxy metrics with no human raters; the full method and limitations are in docs/ABLATIONS_AND_EVALUATION.md.

How we built it

  • Next.js 16 + TypeScript on Google Cloud Run. All Qloo and model calls run server-side.
  • A strict Qloo client (src/lib/qloo): hackathon host, X-Api-Key header, and a per-type parameter allow-list. Qloo silently ignores unsupported parameters, so we fail loudly instead. It also has bounded retries with Retry-After, a process-wide concurrency gate, coalescing of identical requests, per-run call budgets, a private TTL cache and a full call log for provenance.
  • Qloo endpoints in the product: /search (namesakes and audience anchors), /v2/insights with filter.results.entities (audience-specific affinity), paged Insights (live rank calibration), urn:tag (connotation) and urn:demographics (fan skew).
  • Rank calibration. We found live that Qloo affinity is compressed: a brand at rank 50 scores about 0.90 and one at rank 5,000 about 0.70 for the same audience. So NameRadar pages through each audience's own Insights ranking and converts affinity into an estimated rank. That gives meaningful, explainable verdicts ("≈ #390 of this audience's brands" versus "outside their top 5,000").
  • The agent loop has a Claude tool-use planner with three tools (scan_names, inspect_collision, submit_report) and a deterministic fallback planner. The server enforces honesty in both: no unscreened name can be recommended, verdicts always come from Qloo scans (never from a model), and evidence ids are filtered to entities Qloo actually returned. The public demo runs the deterministic planner because no LLM key is configured on it.
  • Tests: 47 unit and provider-contract tests (request shape, auth header, validation of silently-ignored combinations, 429/Retry-After handling, budget, cache, key non-leakage, calibration maths, audience-conditional verdicts). Playwright end-to-end tests cover the full visitor journey on desktop and mobile. There is also a live conformance probe and a pre-registered live ablation.

Challenges we ran into

  • Raw affinity was unusable as a score. Our first version marked almost everything red for everyone. Calibrating against each audience's own ranking fixed it, and gave users a number they can read.
  • The live API differs from the docs. urn:entity:video_game returns 400 and urn:entity:videogame works. Heatmap boundary values differ from the parameter reference. filter.results.entities returns nothing for video-game ids. All of this is documented in docs/QLOO_API_CONFORMANCE.md.
  • Rate limits. A first evaluation run lost 15 calls to 429s, which silently weakened verdicts. We added a shared concurrency gate and re-ran, and we report only the clean run.

Accomplishments we're proud of

  • The audience flip: a ten-second, visible proof that Qloo is load-bearing.
  • Every verdict is explainable term by term and traceable to real Qloo calls.
  • An upstream open-source contribution to the official qloo/qloo-hackathon-kit: a regression-tested troubleshooting entry for Insights filter.type 403 / TOOL_INPUT failures, prepared and ready to submit.

What we learned

Taste is relative. The interesting signal isn't "is this popular?" but "where does this sit in this audience's taste?" Getting that right needed the audience's own distribution, not a global threshold.

What's next

  • Phonetic and cross-language near-miss search, and regional heatmaps for local businesses.
  • Integrations where names are born: incorporation flows, domain registrars, Shopify store setup and naming agencies.
  • An API for brand teams to screen product-line names in bulk.

Honest limits

NameRadar is a cultural pre-screen, not legal advice or trademark clearance. "Green" means no namesake your audience strongly cares about was found in Qloo's graph, not that the word is unused. Albums and very small local businesses may be missed. Qloo affinities are aggregate taste signals, not predictions about individuals. Hackathon Qloo keys expire after the event.

Built with

Qloo Taste AI API, Next.js, React, TypeScript, Tailwind CSS, Zod, Google Cloud Run, Secret Manager, Vitest, Playwright

Built With

  • google-cloud-run
  • next.js
  • playwright
  • qloo-taste-ai-api
  • react
  • secret-manager
  • tailwind-css
  • typescript
  • vitest
  • zod
Share this project:

Updates

Submission history